Починим ваш проект! или записки из паровозного депо
Осенью прошлого года вышла статья «ДЕДская железная дорога» о типичных ошибках в проектах внедрения ERP, которые приводят команду проекта в весьма странные места.
Как это ни удивительно, места, описанные в статье, оказались настолько привлекательны, что их посещаемость за прошедший год не изменилась. Поток запросов в компанию ИТРП на ремонт кем-то “почти сделанных проектов” не ослабевает. Был даже отмечен своеобразный «антирекорд». За два года в рамках одного проекта сотрудники завода, привлеченные к проекту, смогли посетить больше половины мест, описанных в статье.
К нам обратилось предприятие, проект создания ERP-системы которого начался с командой, имеющей опыт создания только учетных программ, закономерно попав в «Саргассово море» непонимания логики работы ERP-системы.
Оттуда проект был извлечен силами сменённой внешней команды, но, как вскоре выяснилось – чтобы, побывав в железнодорожном тупике «Не с того начали» отсутствия внятной методологии внедрения, быть загнанным на минное поле «Чего изволите». На котором взрывами бессистемных доработок и дописок оказалось уничтожено проектное управление.
Тут нужно отдать должное мужеству и героизму сотрудников Заказчика, вовлеченных в проект. Потребность в системе оказалась настолько велика, что они собственными силами, буквально «на руках», вынесли проект с минного поля… И занесли его в «Мраморный карьер» создания однобоких систем, где он пока и находится. К сожалению, силы кончились, деньги израсходованы. Этот случай примечателен только масштабом «путешествия». Основная масса похожих проектов останавливается в каком-то одном месте, реже посещается два.
Проект создания системы автоматизированного управления предприятием ERP класса просто не может быть быстрым и несложным. Это не только «как настроить программу», но много организационных изменений внутри предприятия. Мы сейчас не говорим о проектах, где был использован программный продукт 1С:ERP как инструмент создания учетной системы, такой большой дорогой бухгалтерской программы. Речь идет о проектах, цель которых – создание полного цикла управления. О системах, планирующих – управляющих исполнением – учитывающих результат – помогающих корректировать следующий план. Такие системы создаются в сроки от одного года. Быстрее просто не получится. И риск загнать такой проект в тупик или пустить по кольцевой ветке и диспетчеров на станциях не обойтись.
Анализ и систематизация накопленного опыта «ремонтно-восстановительных работ», проводимых нашими экспертами на свернувших не туда проектах подсказал достаточно простое решение. Внешний аудит. Не нужно ждать признаков, что вы заехали в одно из тех самых странных мест. Два–три раза за проект стоит привлечь внешних экспертов, просто чтобы услышать их мнение, все ли правильно делается. Пусть постоят рядом с проезжающим поездом вашего проекта и посмотрят – не валит ли дым от давно заклинивших подшипников, не падает ли из вагонов груз, да и вообще – же, сколько было в начале? Пусть во время короткой остановки обойдут состав, постучат по колесным парам – нет ли трещины. Несколько дней на контрольную проверку – это значительно проще, чем перезапуск проекта. Как правило, такая проверка может проходить в неформальном формате – знакомства с существующей проектной документацией, разговора с руководителем проекта со стороны Заказчика и со стороны команды исполнителя вполне достаточно эксперту для вердикта – все хорошо, можно двигаться дальше или требуется более внимательно и вдумчиво проанализировать полученные результаты, похоже, что что-то сломалось или вот-вот выйдет из строя.
К сожалению, чаще экспертам компании ИТРП приходится сталкиваться с ситуацией «Все, приехали! Станция? Нет, рельсы закончились!» и тут уже «постукиванием по колесам» не обойтись. В среднем, в зависимости от сложности и масштаба предприятия, диагностика проекта в состоянии, когда Заказчик говорит «мы понимаем, что что-то идет сильно не так» занимает от двух недель до месяца.
Компанией «Институт типовых решений – Производство» для такой диагностики проектов на производственных предприятиях был разработан стандартный план проведения аудита.
Укрупненно аудит делится на две части: проверка «паровоза» информационной системы и «путей» хода проекта.
Проверяем информационную систему – настройки, полноту и достоверность информации, правильность выбранных методов реализации бизнес-процессов:
Номенклатура.
- Структурированность и информативность наименований номенклатуры;
- Наличие и структурированность сведений о параметрах номенклатуры;
- Обоснованность использования характеристик номенклатуры – плюсы и минусы (минусов обычно оказывается больше);
- Обоснованность построения складской аналитики (разделение между нормативными и оперативными позициями – номенклатура/серии/партии);
- Потенциальное наличие дублей (приблизительно процент номенклатуры с дублями);
- Неактуальные (исторические позиции) – количество и процент позиций, по которым не было движений и остатков в течение последнего года;
- Соответствие номенклатурных позиций складского учета материалов (в остатках) и КТД: входными позициями спецификаций (в процентах);
Спецификации, технологические карты:
- Наличие по актуальным позициям готовой продукции и полуфабрикатов;
- Степень наполнения спецификаций и техкарт с перечнем отсутствующих данных, критичных для выполнения функций планирования и диспетчеризации производства, управления потребностями в материальных, трудовых ресурсах, времени работы оборудования;
- Обоснованность методических решений по структуре спецификаций (этапность, разделение по видам рабочих центров). Обосновано/необоснованно/комментарий;
- Наличие процедур (и их исполнение) по вводу и корректировке спецификаций и техкарт, их непрерывной актуализации;
- Мнение ключевых пользователей о достоверности справочника.
Состояние системных справочников. Заполненность и обоснованность структуры:
- Виды номенклатуры;
- Группы финансового учета номенклатуры;
- Структура предприятия;
- Склады и помещения.
Проектные методические решения и их реализация, в т. ч.
- Состояние данных по учету затрат и расчету себестоимости
- Перечень настроек, влияющих на расчет себестоимости, и соответствие каждой настройки целям проекта (потребностям бизнеса) и учетной политике.
- Соответствие предложенной методологии управления производством (планирование, диспетчеризация) реальным потребностям бизнеса (если стоят соответствующие задачи).
- Мнение пользователей, руководителей о состоянии системы и проекта с комментариями эксперта)
Анализируем ход проекта, наличие внятных инструментов управления проектом, применимость подходов, достоверность информации о ходе исполнения проекта:
Анализ применяемой технологии проектных работ:
- Выполненный этап / вид услуг.
- Комментарий по последствиям для проекта используемого подхода и технологии.
- Комментарий по оптимальной организации услуг, работ и технологии.
- Комментарий по наличию документации, ее качеству и целостности.
- Признак: соответствует технологии рекомендованной 1С/соответствует частично/не соответствует
Анализ последних доработок (не более 5-ти, на выбор заказчика) в виде таблицы:
- Мероприятие/доработка
- Комментарий по корректности с точки зрения возможности использования типового функционала вместо доработки.
- Комментарий по соответствию внешним целям проекта (обоснованность).
- Комментарий по системности.
- Комментарий по наличию документации, ее качеству и целостности.
- Признаки: соответствие целям проекта: соответствует/соответствует частично/не соответствует. Системность: системно/не системно.
По итогам результатов проверки разрабатывается, согласуется с Заказчиком план дальнейшего развития проекта, учитывающий фактическую и запланированную готовность уже реализованных блоков, доступность ресурсов, описывающий реализацию проекта в виде Задач.
Отдельно даются рекомендации Заказчику по проведению организационных мероприятий внутри компании и изменениям в составе и мотивации команды проекта.
Если причинами проблем проекта окажется недостаток опыта и знаний команды, то по итогам аудита может быть предложена экспертно-консультационная помощь. Специалисты компании ИТРП, имеющие опыт реализации сложных задач на аналогичном типе производства, помогут в выборе методических решений, проконсультируют, расскажут о том, как похожие проблемы были решены на уже реализованных проектах, окажут помощь в функциональном моделировании. Иногда полезной оказывается услуга “прокачки” команды – составление плана по прохождению обучающих курсов, контроль качества обучения, помощь в применении полученных знаний.
Столкнулись с похожей ситуацией? Обращайтесь, поможем!
Автор: Егор Грациано