Почему экономить на предпроектном обследовании — всегда плохая идея

Любой бизнес стремится к урезанию расходов и ищет пути для экономии. В отношении проектов по внедрению корпоративных систем эта экономия нередко приходится на этап предпроектного обследования. Заказчики ведутся на заверения недобросовестных интеграторов, которые обещают дешевое и быстрое внедрение ERP-системы даже без необходимости выезда на объект. Однако, как правило, такой подход впоследствии только увеличивает бюджет и сроки проекта. По итогу внедряемый продукт не соответствует потребностям компании, а линейный персонал не понимает, зачем нужна новая система и как ею пользоваться.

Предпроектное обследование необходимо, чтобы интегратор мог качественно кастомизировать ERP-систему под нужды заказчика. Если этот этап пропустить, то разработчики будут следовать обратной логике и пытаться подогнать бизнес заказчика под типовой продукт, что неэффективно. Ни один крупный бизнес — а ERP — это система для крупного бизнеса — не укладывается в «коробочное» решение. Компания-интегратор должна выехать на объект, глубоко вникнуть в процессы заказчика, выявить все специфические особенности бизнеса и утвердить детальный план работ. Хотя этот этап может занять до нескольких месяцев, он является необходимым для успешного внедрения ERP-системы. Как все это выглядит в жизни — расскажу на примере из нашей практики.

Реальный опыт обследования

Некоторое время назад мы работали с крупным заказчиком из сферы пищевой промышленности. Задача была поставлена следующим образом: автоматизировать все блоки учета и реализовать выгрузку данных в чистые бухгалтерские базы для формирования отчетности. Поскольку в компании были сложные производственные процессы, в качестве ядра автоматизации была выбрана система «1С:ERP».

С самого начала мы столкнулись с рядом проблем:

1. Бухгалтерский отдел, финансовая служба и IT-подразделение внутри заказчика практически не контактировали между собой, что сильно затрудняло любую коммуникацию.
   
2. ИТ-служба заказчика стремилась взять внедрение под свой контроль, делая систему под себя и ориентируясь на собственный бюджет.
   
3. Бухгалтерская и финансовая службы конфликтовали по вопросам открытия периодов и формирования отчетности. Бухгалтерская служба в принципе была против изменений, так как не хотела мигрировать на новую систему. Инициатива исходила от финансовой службы.
   
4. Заказчик оперировал специфической моделью учета. Часть операций велась в отдельной Excel-базе.

Необходимость бизнес-анализа была очевидной. Долго уговаривать заказчика нам не пришлось: клиент уже приглашал других подрядчиков, но автоматизация так и не «взлетела». Так было принято решение провести предпроектное обследование в рамках небольшого отдельного договора. Мы должны были познакомиться с заказчиком, изучить существующую IT-инфраструктуру, влиться в процессы, требующие автоматизации, и понять, какие лица несут ответственность и принимают решения на каждом из блоков. На выходе мы должны были определить понятные функциональные требования и сделать более точную оценку бюджета.

Чтобы разрешить проблему №2 (неограниченная зона ответственности ИТ-службы заказчика), мы провели совещание с генеральным директором и письменно зафиксировали моменты, в которые может вмешиваться внутренняя ИТ-служба компании. Спорные моменты выносились на общее совещание с руководителем проекта на стороне заказчика и далее решались через административный ресурс.

Следующий шаг — составить детальный план обследования исходя из автоматизируемых блоков. Верхнеуровнево наш план выглядел так:

• входная информация для первичных документов (выгрузки из R-Keeper и сторонних систем);
  
  
• загрузка данных в ERP-систему;
  
  
• перенос остатков товаров и инвентаризация;
  
  
• учет производства в ERP;
  
  
• перенос остатков из бухгалтерской базы и начало ведения учета по нескольким юридическим лицам;
  
  
• реализация блока платежей;
  
  
• частичная автоматизация бюджетирования;
  
  
• внесение, учет управленческих операций;
  
  
• управленческая отчетность;
  
  
• выгрузка части данных в бухгалтерскую базу и предоставление отчетности в ФНС.
  
  

Обследование было решено проводить на территории заказчика. Наши специалисты ежедневно выезжали на объекты и общались с людьми на местах. В своем офисе мы занимались только оформлением документов. Отдельно отмечу, что все интервью записывались на звуковой носитель. Это помогло при формировании корректных выходных документов и разрешении спорных ситуаций. Таким образом мы справились с проблемами №3 (конфликт финансовой службы и бухгалтерии) и №4 (непрозрачность учета).

В ходе интервью мы опрашивали специалистов об их роли в конкретных бизнес-процессах, узнавали, с какими входящими и исходящими данными они работают, с какими проблемами сталкиваются, как взаимодействуют со смежными отделами, как именно обмениваются информацией и чего ожидают от новой информационной системы.

Перед проведением интервью мы заранее попросили всех участников тезисно подготовить свое видение ответственности и процессов в будущей системе, а также выделить сильные стороны этих предложений (слабые мы определяли самостоятельно). Проанализировав все идеи, мы назначили несколько встреч с генеральным директором и представителями каждой задействованной службы заказчика. На встречах мы обозначали позиции всех сторон и предлагали оптимальные, с нашей точки зрения, решения. Последнее слово оставалось, разумеется, за гендиректором компании. В соответствии с его решением, мы либо утверждали идею, либо снимали вопрос с повестки, либо направляли предложение на доработку. Такой подход помог нивелировать противостояние и примирить между собой различные службы заказчика.

На комплексное обследование у нас ушло около месяца. По итогам анализа заказчик получил:

• уверенность в том, что внедрение необходимо;
  
  
• обоснованные ориентиры по стоимости и длительности будущего проекта;
  
  
• уточненные границы проекта (в частности, за рамки был вынесен один из функциональных блоков, так как в компании сменился руководитель отдела и было решено, что с приходом нового менеджера бизнес-процессы могут измениться);
  
  
• понимание приоритетных участков автоматизации и узких мест бизнес-процессов.
  
  

Что учесть при обследовании

На основе нашего опыта я бы выделил 10 простых и понятных шагов, которых стоит придерживаться при проведении предпроектного обследования:

1. Познакомиться с заказчиком и найти «союзников» и заинтересованные в успехе проекта стороны.
   
2. Определить административный ресурс и ответственного за проект на стороне заказчика.
   
3. Заключить отдельный договор на обследование с четко прописанным результатом.
   
4. Договориться о работе в офисе заказчика.
   
5. Выбрать сотрудника, который сможет глубоко погрузиться в процессы и будет выступать в роли ответственного лица от исполнителя (а не просто менеджера проекта). Привлечь всех нужных специалистов (администраторов, методологов и архитекторов по каждому блоку автоматизации).
   
6. Разработать детальный план обследования исходя из автоматизируемых блоков.
   
7. Создать график встреч с сотрудниками компании-заказчика в соответствии с планом и согласовать его у лица, принимающего решения от заказчика.
   
8. Проконтролировать обязательное ведение аудиозаписи всех интервью.
   
9. Проанализировать эффективность и корректность бизнес-процессов — возможно, они потребуют улучшения перед началом автоматизации или поменяются по тем или иным причинам.
   
10. Обеспечить ежедневное ведение статуса обследования и актуализацию текущих и будущих рисков.
    
    

Вывод

Золотое правило любого проекта — обо всем договориться заранее, чтобы предотвратить неприятные сюрпризы для всех участников процесса. Поначалу предпроектное обследование может показаться излишним расходом средств и времени, но в долгосрочной перспективе этот этап поможет правильно спланировать бюджет и уменьшить риски внедрения, а также даст уверенность в том, что ERP-система принесет компании ожидаемую пользу.

Читать в СМИ