Подбирая идею для очередного материала блога, мы обратились к нашим специалистам — руководителям проектов внедрения 1С:ERP, и выяснили, что одной из самых неоднозначных тем, которые возникают при общении с заказчиками, является выбор методологии, по которой будет строиться рабочий процесс. Казалось бы, что в этом сложного, бери любую, или ту, которая больше нравится, и делай, но все не так просто.
Дело в том, что выбор методологии в случае проекта внедрения 1С:ERP (либо других ERP-систем) определяет и сроки работ, и их стоимость, а также объем и интенсивность загрузки персонала заказчика и то, как быстро предприятие начнет использовать новую систему 1С:ERP и многое другое. Именно поэтому подробный диалог на эту тему происходит на первой же встрече команды внедренцев и представителей заказчика. А окончательное решение остается на завершение этапа обследования. О том, почему это так важно, и как выбор методики определяет успешность проекта внедрения 1С:ERP, мы подробно рассмотрим в нашей статье.
Классическая методология внедрения ERP
Как правило, команда внедренцев предлагает на выбор две методологии внедрения ERP — классическую (последовательную, водопадную) и гибкую (параллельную, Agile). Первая предполагает последовательные этапы работы, которые следуют один за другим четко и планомерно. Сначала обследование, затем моделирование и проектирование, разработка и реализация, загрузка первоначальных данных, обучение пользователей, после — опытная и промышленная эксплуатация, а по завершении основных работ— пост проектное сопровождение.
Это можно сравнить со строительством небоскреба, когда сначала проводятся геологические изыскания, потом создается проект, он принимается к реализации, а потом начинается возведение здания: первым делом фундамент, далее вся конструкция этаж за этажом.
Классическая методология в разработке или внедрении информационных систем характеризуется наличием подробных планов, проектов, технических заданий, инструкций, детальной проработкой каждого пункта «на бумаге». Как правило, при классическом подходе по итогу обследования компания-внедренец может с высокой долей точности назвать сроки и стоимость проекта.
Кстати, стоит сказать, что водопадная методика внедрения ERP обычно применяется при реализации проектов автоматизации учета в госучреждениях, бюджетных организациях, когда важно иметь подтверждающие документы по каждому этапу, работать в рамках жестко фиксированного бюджета и сроков.
Данная методология внедрения ERP активно используется в разработках программного обеспечения и информационных систем с 70-х годов и имеет широкий опыт применения. Многие внедренческие компании и сейчас предпочитают работать по классике.
Правда, при таком последовательном подходе (учитывая масштабность системы 1С:ERP) первые результаты заказчик почувствует чуть ли не через год. Первые месяцы работ будут заняты моделированием и проектированием всех подсистем, детальным описанием процессов «как есть» и «как будет», разработкой детальных технических заданий на доработке – в результате этих работ обычно создаются сотни или даже тысячи страниц проектной документации.
То есть, по сути, компания-заказчик платит немаленькие деньги за то, что не может оценить, попробовать, протестировать на реальных данных. Конечно, в течение года подрядчик регулярно присылает отчеты о проделанной работе, отправляет схемы, планы, визуализацию отдельных процессов, модели «как есть» и «как будет», технические задания, но это все теория. До практики (реального использования системы 1С:ERP) дело дойдет лишь тогда, когда заказчик утвердит и согласует проработанные проектные документы.
Еще одна опасность водопадной методологии состоит в том, что если подрядчик оказывается недостаточно опытным, то какая-либо ошибка или неточность, совершенная на этапе проектирования и обнаруженная только при опытной эксплуатации, может повлечь за собой дополнительные трудозатраты на ее устранение, а дополнительных ресурсов на это в проекте уже может уже и не быть.
Еще один момент, это занятость куратора проекта на стороне заказчика в течение процесса внедрения. При работе по данной методике общение с командой подрядчика чуть менее интенсивное, чем при Agile. В течение этапов моделирования, проектирования и разработки оно сводится к согласованию присланной документации, уточнении, подтверждении каких-то моментов, на этапах опытной и промышленной эксплуатации взаимодействие уже более плотное, но в любом случае не такое активное, как того требуют гибкие методики.
В целом, классическая методология внедрения ERP, учитывая долгую историю применения, несомненно, способна обеспечить успешное завершение проекта внедрения 1С:ERP. Комфортное партнерство, в данном случае, определяется четкими обязательствами подрядчика по срокам, цене внедрения, подробной документацией по каждому блоку, подсистеме, процессу, а также доверием заказчика команде-внедренцев и готовностью дождаться результатов проекта.
Но, как мы уже упоминали, водопадная методология имеет ряд недостатков:
-
Команда проекта долго работает «в стол»: создает тома проектной документации – это сильно увеличивает стоимость и сроки проекта, обычно не менее, чем на 30-40%.
-
Часто заказчику сложно понять, что предлагает исполнитель, не «пощупав» систему, потому что 1С:ERP 2 система сложная и объемная. Доработки, описанные на бумаге, потом могут совсем не подойти, и поймет это заказчик уже на этапе опытной эксплуатации. Не редки случаи, когда переделки системы в процессе опытной эксплуатации достигают до 30-40%, что опять же значительно влияет на увеличение стоимости и сроков проекта.
Гибкие методологии внедрения ERP-систем
Совсем другой подход предлагают методологи Agile. По их мнению, классическая модель внедрения ERP-систем слишком неповоротлива, бюрократична и не позволяет быстро реагировать на потребности заказчика.
При использовании agile-методов внедрения работа строится короткими циклами — итерациями, которые длятся по 2-4 недели. Перед каждым циклом происходит оценка приоритетности задач. Например, заказчик говорит, что есть острая потребности решить проблемы склада. Не вопрос. Ставим автоматизацию складского учета на первое место. Кстати, как правило, при данной методологии работа строится даже более мелкими задачам, например, разработать и реализовать механизмы ввода и редактирования основной нормативно-справочной информации, реализовать схему учета продукции на складе готовой продукции, потом реализовать учет на складах учета сырья и материалов и т.д.
Гибкая методология внедрения ERP-систем ставит своей целью в короткие сроки представить «минимально жизнеспособный продукт», который еще не является идеальным, но зато способен решить какую-то насущную проблему. Каждый цикл включает моделирование, разработку, тестирование, демонстрацию, и таких итераций может быть сколько угодно много, пока все задачи проекта не будут закрыты.
Методологи Agile считают, что лучше уделить больше времени коммуникации с клиентом, чем написанию томов проектной документации. А показывать итог работы предпочтительнее на готовом продукте, нежели на бумаге.
При таком подходе уже через 2-3 месяца заказчику могут быть представлены первые результаты.
Например, в нашей практике был случай, когда заказчик пришел за решением актуальных проблем со складом. Выяснив все потребности предприятия, мы предложили внедрять 1С:ERP, но по гибкой методике, то есть первым делом настроить работу склада.
В итоге уже через 2,5 месяца заказчик получил работающий модуль складского учета на базе 1С:ERP, снизил затраты на инвентаризацию и упростил работу сотрудников склада и менеджеров по закупкам. То есть, смог пользоваться результатами внедрения задолго до завершения всего проекта.
Гибкая методология внедрения ERP предполагает очень интенсивное общение куратора проекта со стороны заказчика и руководителя проекта внедрения, частые встречи рабочих групп заказчика и подрядчика. Как правило, совещание происходят каждую недели, а связь с куратором поддерживается практически 24/7, особенно, если речь идет о круглосуточном производстве.
Вот как описывает, один из моментов рабочего процесса наш специалист: «Настроили учет брака. Вечером кидаю в группу в Whatsapp сообщение, что теперь учет брака ведется по таким-то параметрам, вот скриншот и инструкция на две странички. Утром обратная связь. Если, все нормально, беремся за следующую задачу. Есть проблемы — возвращаемся и дорабатываем».
Активная коммуникация с заказчиком, оперативное решение задач, быстрое получение первых результатов, - несомненные, плюсы agile-методов. Но есть и минусы. К примеру, при выборе данной методики специалисты могут сказать только вилку цен за внедрение 1С: ERP 2 (цена от … цена до …), также есть некая неопределенность по срокам всего проекта. Также в данном случае не предполагается прикладывать к отчету об итогах работы подшивку с подробными техническими заданиями и проектной документацией, так как практически все вопросы решаются по ходу внедрения.
Agile-методы являются идеальными для средних компаний — производственные и торговые предприятия с численностью сотрудников 200-1000 человек. По словам наших специалистов, они могут активно применяться в компаниях и с большим числом сотрудников, но возможно, уже с сочетаниями элементов классических методик.
Успешность внедрения 1С:ERP по гибкой методологии определяется относительно быстрыми видимыми результатами: компания-заказчик получает стимул продолжать работы, углубляться в процессы, совершенствовать учет; а также большей вовлеченностью и куратора, и сотрудников предприятия-заказчика в рабочий процесс.
Гибридные методологии внедрения 1С:ERP
Мы уже обмолвились в предыдущем пункте о том, что эти две методологии внедрения 1С:ERP 2 могут сочетаться. И, по правде говоря, так обычно и происходит. После обследования намечаются функциональные блоки автоматизации, а затем происходит работа по этим блокам. Причем по конкретному блоку может быть проведено моделирование и проектирование, реализация и запуск, а объем проектной документации, полученные в ходе процесса проектирования, может быть сокращен (например, можно не писать модели «как есть», только «как будет», не составлять подробных технических заданий на доработки – только их концептуальное описание и т.д.).
При реализации доработок и при запуске какой-либо подсистемы как раз может быть применен Agile подход, когда итеративным методом реализуются доработки, демонстрируются заказчику, а на основе обратной связи от пользователей, вносятся корректировки и т.д.
То есть, в этом случае сохраняются некоторые процессы моделирования и проектирования, но в несколько упрощенном виде, и заказчик получает видимый результат несколько быстрее, чем при традиционной водопадной модели.
Кроме того, за счет сокращения и упрощения проектной документации, снижаются трудозатраты проекта, а значит сроки и стоимость работ. Но все же за счет применения методологии гибкой разработки внутри функционального блока стоимость и сроки проекта так же могут «плавать», но в гораздо меньшем объеме, чем при применении классического Agile подхода.
В нашей практике был такой прецедент, когда мы буквально за 3 месяца смоделировали и запустили весь контур учета (то есть применили классический подход), но в очень простом виде, с упрощенной проектной документацией. А затем начали углублять автоматизацию учета строго по Agile, решая задачи по потребностям компании и сотрудников.
В заключение, отметим, что все представленные методологии внедрения ERP могут обеспечить успешную реализацию проекта внедрения, они не являются плохими или хорошими сами по себе. У каждой из представленных методологий есть свои преимущества и недостатки. Заказчику и подрядчику проекта важно выбрать именно ту методологию, которая наиболее подходит под конкретный проект автоматизации, для конкретного предприятия и под конкретную команду внедренцев.
Читайте также:
Остались вопросы?
