Обзор подготовлен	При поддержке

Евгения Ильина: Объем модификаций — основная переменная, от которой зависит масштаб проекта

Об особенностях проектов внедрения систем автоматизации рассказывает в интервью CNews Евгения Ильина, генеральный директор AXON-Consulting.

CNews: Какие основные подходы к внедрению систем автоматизации видятся вам в настоящий момент наиболее эффективными?

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

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

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

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

Безусловно, даже в самом начале проекта, не дожидаясь момента окончательного формирования технического задания, можно управлять основными параметрами проекта. Для этого, в самом начале проектных работ важно всем участникам проекта, как со стороны компании, так и со стороны консультанта, договориться о правилах "игры": быстро и качественно или не спеша, но со вкусом.

CNews: Насколько, из вашей практики, корпоративный сектор готов довольствоваться стандартной функциональностью предлагаемых решений?

Евгения Ильина: Общеизвестно, что все программные продукты обладают определенным набором функциональности. Одни — более обширным, другие — более ограниченным и специализированным. Для решения конкретных бизнес задач в каждом случае может быть использован стандартный инструментарий системы или разработан новый функционал. В каждом конкретном случае принимается решение — каким образом реализовывать требование. Как правило, в современных системах практически любая задача может быть решена различными способами и, безусловно, чем более опытен и квалифицирован консультант, участвующий в проекте, тем больше возможных решений он предложит. Но, в любом случае, решение принимать предстоит заказчику. Поэтому, если вы хотите внедрить систему максимально быстро и наименее болезненно, то ваш выбор — стандартная функциональность выбранного программного продукта с минимальным количеством изменений. Если вы хотите создать абсолютно уникальный продукт, полностью адаптированный под всю возможную специфику вашей бизнес модели, нужно быть готовым к тому, что это будет долго и дорого, а экономический эффект от внедрения будет достигнут много позже.

CNews: Какова, по вашему опыту, средняя продолжительность проекта автоматизации в настоящий момент?

Евгения Ильина: Независимо от того, какой из вышеперечисленных путей будет выбран, проект внедрения займет несколько месяцев, необходимых для проведения всех проектных работ, а именно: анализа текущей деятельности, дизайна, построения решения, проведения тестирования, обучения персонала, переноса исторических данных и запуска в промышленную эксплуатацию.

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

CNews: Какие решения, на ваш взгляд, более востребованы сегодня рынком — тиражируемые или заказные? Какими преимуществами систем это обусловлено?

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

Безусловно, при внедрении готовых решений возможна значительная оптимизация сроков внедрения. А время, как известно, самый ценный ресурс в погоне за прогрессом. Но, наравне с этим, внедрение готовых решений несёт в себе огромное количество рисков, которые не всегда очевидны и оправданы. Приобретая готовое решение, следует понимать, что помимо настроенной и отлаженной функциональности вы приобретаете готовую бизнес модель, которую вам необходимо понять и принять. Более того, эта модель включает в себя и организационную структуру, которую также необходимо учесть.

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

Так же необходимо понимать, что если вы рассчитываете купить готовый коробочный продукт, разработанный на базе современной ERP-системы, то вас может постигнуть разочарование. Любое решение, предлагаемое на рынке, требует кастомизации. И это обусловлено не только спецификой каждого конкретного предприятия, но и стремительными изменениями окружающей нас действительности. Даже если вы очень решительны, вам потребуется время на то, чтобы изучить предложение, договориться с продавцом, заключить договор. К моменту вашего обладания вожделенным продуктом может пройти от нескольких недель до нескольких месяцев. С большой долей вероятности можно утверждать, что за этот период будут приняты новые законы, приняты или отменены налоги, изменены тарифы, ставки, методы расчета и так далее. Результат — точка актуальности упущена, необходима доработка решения.

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

Например, ваш отдел закупок насчитывает 15 сотрудников, которые целыми днями набивают заявки на поставку, а затем закупки. При внедрении системы, в которой полностью автоматизирован процесс планирования закупок и последующего заказа товаров у поставщиков, перед вами встанет проблема перераспределения функциональных обязанностей сотрудников или их сокращения. Причем, если вы это будете решать в момент запуска системы, то, как минимум это обернется хаосом, а в худшем случае — саботажем сотрудников и срывом запуска.  Или, например, при приеме товара от поставщика, кладовщик, не разбираясь, принимает все, что ему привезли, даже если это не было заказано. В рамках системы в функциональные обязанности кладовщика входит подтверждение количества принятого товара, в ранее созданной накладной на закупку. Возможности добавить новый товар или удалить имеющийся кладовщик, по понятным причинам, не имеет. В результате, товар, не указанный в накладной, но фактически принятый остается полностью неучтенным. А дальше вы выясняете отношения уже с поставщиком, который утверждает, что поставил вам новый товар, а вы утверждаете, что в глаза его не видели и платить за него  не будете. Хорошо, если этот неучтенный товар остался на складе до инвентаризации. А если был привезен в магазин и выставлен на полки? Покупатель будет удивлен, почему батон колбасы, который он держит в руках, не может быть ему продан, так как отсутствует в остатках по базе данных, и на него нет цены.

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

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

CNews: Как бы вы охарактеризовали структуру инвестиций в подобные проекты?

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

При внедрении готового решения, в перечне прямых затрат стоит учесть также  и стоимость самого решения. Учитывая, что стоимость решения — удовольствие не из дешёвых, необходимо быть уверенным, что вы приобретаете то, что вам нужно.

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

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

CNews: В чем вы видите специфику внедрения готового решения, по сравнению с полномасштабным проектом?

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

Следующим этапом после анализа осуществляется расстановка приоритетов между всеми заявками на изменения. Каким бы идеальным не было решение, у пользователя всегда найдутся пожелания. Причем, этот процесс вечен! Поэтому крайне важно управлять им. Для выполнения выделяются только критичные для запуска модификации. Это делается для того, чтобы процесс построения системы был минимально коротким, а процесс адаптации решения не перерос в полномасштабный проект. В дальнейшем, уже после запуска решения в процесс промышленной эксплуатации, все отклоненные дополнительные требования могут быть рассмотрены повторно. Причем, лучше всего это делать не сразу после запуска, а по истечении некоторого времени, необходимого для привыкания пользователей к работе с новой системой, а может и с новой моделью бизнес-процессов. В этом случае, наиболее велика вероятность того, что часть требований, вызванных желанием пользователей изменить интерфейс и функциональность системы до «привычного» вида, продиктованного старым ПО или привычным бизнес-процессом (иногда морально устаревшим), отпадет сама собой. Хотя данный подход так же рекомендуется и при стандартном методе внедрения систем автоматизации.

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

При удачном раскладе, от начала проекта до запуска решения в промышленную эксплуатацию может пройти всего 1,5 — 2 месяца, что по сравнению с обычным проектом внедрения является суперрезультатом. И не смотря на все риски, оно того стоит.  Конечно, идеальный вариант, когда ваш бизнес на этапе становления, и вы заранее озаботились его автоматизацией. Или, например, вы построили распределительный центр, но пока ни персонала, ни бизнес-процессов нет, и можно все начать с чистого листа и сделать сразу всё по уму. Но даже если ваш бизнес в самом расцвете, а устаревшие технологии сдерживают ваш дальнейший рост, при грамотном подходе, оценив и минимизировав все риски, вы имеете все шансы на успех. 

CNews: Спасибо.