Почему экономить на предпроектном обследовании — всегда плохая идея
Почему экономить на предпроектном обследовании — всегда плохая идея
Любой бизнес стремится к урезанию расходов и ищет пути для экономии. В отношении проектов по внедрению корпоративных систем эта экономия нередко приходится на этап предпроектного обследования. Заказчики ведутся на заверения недобросовестных интеграторов, которые обещают дешевое и быстрое внедрение ERP-системы даже без необходимости выезда на объект. Однако, как правило, такой подход впоследствии только увеличивает бюджет и сроки проекта. По итогу внедряемый продукт не соответствует потребностям компании, а линейный персонал не понимает, зачем нужна новая система и как ею пользоваться.
Предпроектное обследование необходимо, чтобы интегратор мог качественно кастомизировать ERP-систему под нужды заказчика. Если этот этап пропустить, то разработчики будут следовать обратной логике и пытаться подогнать бизнес заказчика под типовой продукт, что неэффективно. Ни один крупный бизнес — а ERP — это система для крупного бизнеса — не укладывается в «коробочное» решение. Компания-интегратор должна выехать на объект, глубоко вникнуть в процессы заказчика, выявить все специфические особенности бизнеса и утвердить детальный план работ. Хотя этот этап может занять до нескольких месяцев, он является необходимым для успешного внедрения ERP-системы. Как все это выглядит в жизни — расскажу на примере из нашей практики.
Реальный опыт обследования
Некоторое время назад мы работали с крупным заказчиком из сферы пищевой промышленности. Задача была поставлена следующим образом: автоматизировать все блоки учета и реализовать выгрузку данных в чистые бухгалтерские базы для формирования отчетности. Поскольку в компании были сложные производственные процессы, в качестве ядра автоматизации была выбрана система «1С:ERP».
С самого начала мы столкнулись с рядом проблем:
- Бухгалтерский отдел, финансовая служба и IT-подразделение внутри заказчика практически не контактировали между собой, что сильно затрудняло любую коммуникацию.
- ИТ-служба заказчика стремилась взять внедрение под свой контроль, делая систему под себя и ориентируясь на собственный бюджет.
- Бухгалтерская и финансовая службы конфликтовали по вопросам открытия периодов и формирования отчетности. Бухгалтерская служба в принципе была против изменений, так как не хотела мигрировать на новую систему. Инициатива исходила от финансовой службы.
- Заказчик оперировал специфической моделью учета. Часть операций велась в отдельной Excel-базе.
Необходимость бизнес-анализа была очевидной. Долго уговаривать заказчика нам не пришлось: клиент уже приглашал других подрядчиков, но автоматизация так и не «взлетела». Так было принято решение провести предпроектное обследование в рамках небольшого отдельного договора. Мы должны были познакомиться с заказчиком, изучить существующую IT-инфраструктуру, влиться в процессы, требующие автоматизации, и понять, какие лица несут ответственность и принимают решения на каждом из блоков. На выходе мы должны были определить понятные функциональные требования и сделать более точную оценку бюджета.
Чтобы разрешить проблему №2 (неограниченная зона ответственности ИТ-службы заказчика), мы провели совещание с генеральным директором и письменно зафиксировали моменты, в которые может вмешиваться внутренняя ИТ-служба компании. Спорные моменты выносились на общее совещание с руководителем проекта на стороне заказчика и далее решались через административный ресурс.
Следующий шаг — составить детальный план обследования исходя из автоматизируемых блоков. Верхнеуровнево наш план выглядел так:
- входная информация для первичных документов (выгрузки из R-Keeper и сторонних систем);
- загрузка данных в ERP-систему;
- перенос остатков товаров и инвентаризация;
- учет производства в ERP;
- перенос остатков из бухгалтерской базы и начало ведения учета по нескольким юридическим лицам;
- реализация блока платежей;
- частичная автоматизация бюджетирования;
- внесение, учет управленческих операций;
- управленческая отчетность;
- выгрузка части данных в бухгалтерскую базу и предоставление отчетности в ФНС.
Обследование было решено проводить на территории заказчика. Наши специалисты ежедневно выезжали на объекты и общались с людьми на местах. В своем офисе мы занимались только оформлением документов. Отдельно отмечу, что все интервью записывались на звуковой носитель. Это помогло при формировании корректных выходных документов и разрешении спорных ситуаций. Таким образом мы справились с проблемами №3 (конфликт финансовой службы и бухгалтерии) и №4 (непрозрачность учета).
В ходе интервью мы опрашивали специалистов об их роли в конкретных бизнес-процессах, узнавали, с какими входящими и исходящими данными они работают, с какими проблемами сталкиваются, как взаимодействуют со смежными отделами, как именно обмениваются информацией и чего ожидают от новой информационной системы.
Перед проведением интервью мы заранее попросили всех участников тезисно подготовить свое видение ответственности и процессов в будущей системе, а также выделить сильные стороны этих предложений (слабые мы определяли самостоятельно). Проанализировав все идеи, мы назначили несколько встреч с генеральным директором и представителями каждой задействованной службы заказчика. На встречах мы обозначали позиции всех сторон и предлагали оптимальные, с нашей точки зрения, решения. Последнее слово оставалось, разумеется, за гендиректором компании. В соответствии с его решением, мы либо утверждали идею, либо снимали вопрос с повестки, либо направляли предложение на доработку. Такой подход помог нивелировать противостояние и примирить между собой различные службы заказчика.
На комплексное обследование у нас ушло около месяца. По итогам анализа заказчик получил:
- уверенность в том, что внедрение необходимо;
- обоснованные ориентиры по стоимости и длительности будущего проекта;
- уточненные границы проекта (в частности, за рамки был вынесен один из функциональных блоков, так как в компании сменился руководитель отдела и было решено, что с приходом нового менеджера бизнес-процессы могут измениться);
- понимание приоритетных участков автоматизации и узких мест бизнес-процессов.
Что учесть при обследовании
На основе нашего опыта я бы выделил 10 простых и понятных шагов, которых стоит придерживаться при проведении предпроектного обследования:
- Познакомиться с заказчиком и найти «союзников» и заинтересованные в успехе проекта стороны.
- Определить административный ресурс и ответственного за проект на стороне заказчика.
- Заключить отдельный договор на обследование с четко прописанным результатом.
- Договориться о работе в офисе заказчика.
- Выбрать сотрудника, который сможет глубоко погрузиться в процессы и будет выступать в роли ответственного лица от исполнителя (а не просто менеджера проекта). Привлечь всех нужных специалистов (администраторов, методологов и архитекторов по каждому блоку автоматизации).
- Разработать детальный план обследования исходя из автоматизируемых блоков.
- Создать график встреч с сотрудниками компании-заказчика в соответствии с планом и согласовать его у лица, принимающего решения от заказчика.
- Проконтролировать обязательное ведение аудиозаписи всех интервью.
- Проанализировать эффективность и корректность бизнес-процессов — возможно, они потребуют улучшения перед началом автоматизации или поменяются по тем или иным причинам.
- Обеспечить ежедневное ведение статуса обследования и актуализацию текущих и будущих рисков.
Вывод
Золотое правило любого проекта — обо всем договориться заранее, чтобы предотвратить неприятные сюрпризы для всех участников процесса. Поначалу предпроектное обследование может показаться излишним расходом средств и времени, но в долгосрочной перспективе этот этап поможет правильно спланировать бюджет и уменьшить риски внедрения, а также даст уверенность в том, что ERP-система принесет компании ожидаемую пользу.