Внедрение по полному проектному циклу
С чего мы начинаем ?
Прежде всего мы выполняем обследование предприятия, это предварительный этап, необходимый для согласования целей и рамок проекта, плана-графика и бюджета.
Главное, что мы стараемся сделать на этом этапе – внимательно Вас выслушать и понять Ваши цели и проблемы, помочь структурировать информацию, узнать, чем мы можем помочь, в чем видится наша роль. Это не значит, что наша задача «сделать то, что хочет клиент». Наша задача – предложить то, что действительно «нужно».
Проанализировав полученную информацию, обдумав ее, можно увидеть проблему, которая может быть и не видна на первый взгляд, но именно ту, которая портит жизнь. Главное – предложить решение именно этой наболевшей проблемы. Не склонять заказчика к тому, что мы делали много раз и то, что уже умеем делать хорошо и быстро, а искать оптимальное решение, нужное именно в этом конкретном случае.
Технически обследование может проводиться лично, с выездом наших сотрудников на предприятие. Но чаще это делается удаленно, по скайпу или zoom. А если в проекте задействованы специалисты из разных городов или стран, то собеседования онлайн – это единственная возможность. И, надо отметить, на результате это если и сказывается, то только в лучшую сторону, т.к. это более удобно: легче передаются электронные формы, легче сделать запись беседы.
Итак, в течение одной-двух недель мы проводим интервью с ключевыми лицами заказчика, затем готовим и презентуем «Концепцию проекта», документ, в котором прежде всего определены цели проекта:
Целеполагание часто упускается из виду, в виду кажущейся очевидности, но это ключевой момент.
Это не может быть просто «Внедрить систему 1С:ERP», поскольку цель должна быть внешней по отношению к проекту, должна определять, какие преимущества получает бизнес заказчика от проекта. Ну и конечно же она должна соответствовать критериям SMART (specific, measurable, achievable, relevant, timed), т.е. быть конкретной, измеримой, достижимой, релевантной, т.е.: достижимой именно проектом автоматизации и можно определить время, за которое цель будет достигнута.
Также в «Концепции проекта» определяются:
функциональные рамки проекта
ключевые задачи
ключевые методические решения
общие пожелания функциональных заказчиков
особенности организации бизнес-процессов (влияющих на план и бюджет проекта)
фиксация “узких мест” в бизнес процессах
варианты технологии производства работ на проекте
требования к ресурсам Исполнителя и Заказчика для выполнения проекта
схема интеграции систем
план-график проекта со сроками и бюджетами
Разработка и согласование требований. Функциональное моделирование на примере 1С:ERP
Разработка и согласование требований – это совместная работа сотрудников Заказчика и Исполнителя, работа в непрерывном взаимодействии. Для этого на сервере СИНИМЕКС организуется общее пространство проекта на базе Confluence – удобной платформы для ведения документации.
Прежде всего мы проводим обучение системе 1С:ERP ключевых пользователей Заказчика. Для проведения обучения на сервере заказчика устанавливается специальная тестовая база данных, в нее вносятся примеры из реальной деятельности Заказчика. Все уроки записываются, записи выкладываются в общее пользование, что позволяет сотрудникам заказчика отработать примеры и глубже усвоить материал.
Анализ бизнес-процессов, подлежащих автоматизации, ведется путем моделирования контрольных примеров Заказчика на типовом решении 1С:ERP. Команда Заказчика, будущие ключевые пользователи с самого начала проекта вовлекаются в процесс рассмотрения их будущей работы с системой и это выполняется с максимальным использованием типового решения, демонстрации его возможностей. У пользователя есть возможность «пощупать» будущую систему. В confluence мы максимально просто и понятно фиксируем результат сопоставления пользователем его текущей работы и того, как он это будет делать в дальнейшем.
В том случае, если выясняется, что типовое решение не решает задачи заказчика, а состав потенциальных доработок требует дополнительных исследований, то выполняется Функциональное моделирование.
- Проводится выявление «узких мест» бизнес-процессов, и при необходимости формулируются требования к реинжинирингу бизнес-процессов
- Моделирование с привлечением рабочей группы Заказчика выделенных бизнес-процессов предприятия в типовом решении с использованием его стандартного функционала (без доработок конфигурации) на ограниченной выборке данных (контрольном примере):
1. Рабочая группа формирует требования
2. Консультанты моделируют в типовом решения на данных Заказчика
3. Результат обсуждается с Рабочей группой, в модель вносятся изменения
4. Для получения модели может потребоваться несколько итераций моделирования
- При этом у рабочей группы формируется представления о модели бизнес-процессов «Как будет» в 1С:ERP, сценариях работы пользователей, функционале типового решения и возможности его использования для автоматизации бизнес-процессов
- Принятие решений о необходимости реинжиниринга выделенных бизнес-процессов для возможности их автоматизации или для повышения их эффективности и построение модели бизнес-процессов «Как будет» в привязки к функционалу типового решения и его доработкам
- Формирование списка необходимых доработок типового функционала 1С:ERP
В результате функционального моделирования формируется:
Документ «Спецификация требований», модель бизнес-процессов «Как будет» с привязкой к функционалу и интерфейсам, рабочим местам типового решения
Перечень функциональных разрывов - желательных доработок типового решения
База данных с функциональной моделью
При функциональном моделировании Команда Заказчика полностью вовлечена в этот процесс и хорошо себе представляет, что именно мы вместе с ними сейчас делаем, в Confluence шаг за шагом видна разработка. Стадия кодирования менее прозрачна в этом смысле – программисты «ушли» программировать и кто знает, что за результат будет продемонстрирован. НО мы умеем выполнять эту работу с соблюдением принципа «прозрачности» - все задачи по доработкам фиксируются в системе JIRA, каждая задача связана с соответствующим бизнес-процессом в Confluence.
На этом этапе выполняются следующие работы:
- Доработка типового решения в соответствии с требованиями Технического задания
- Тестирование всех доработок
- Разработка и утверждение программы и методики испытаний (ПМИ)
- Испытания и утверждение результатов испытаний
Объем данных для испытаний – это ограниченная выборка информации, объем должен быть достаточен для обеспечения достоверности результата испытаний, но не более того. На рабочем массиве данных, как правило, испытания не проводятся, поскольку рабочий объем данных (нормативных, хозопераций и так далее) формируется на следующем этапе – ввод в действие.
Приемочные испытания проводятся приемочной комиссией, все замечания фиксируются в Протоколе испытаний.
Все замечания протокола ранжируются:
1. Явное невыполнение требований Технического задания на доработки или программные ошибки
2. Дополнительные требования, появившиеся у Заказчика в ходе испытаний. Реализуются как дополнительные работы
3. Возможности типового функционала, требующие дополнительных консультаций. Доработки и исправления не требуются
Запуск системы в опытную эксплуатацию
Опытная эксплуатация ERP-системы проводится только на реальных данных, в условиях, максимально приближенным к рабочим, но на тестовом периоде, с вводом всех данных “задним числом”.
Цель опытной эксплуатации – в процессе практического использования ERP-системы:
- Выявить и реализовать дополнительные требования к ERP-системе, которые по тем или иным причинам не были зафиксированы в модели «Как будет»
- Выявить и исправить несоответствия и прочие ошибки
- Сформировать навыки пользователей и понимание ими методик, заложенных в ERP-систему
- Получить приемлемый результат работы системы на тестовом периоде. Убедиться что система (а это не просто программный продукт, а комплекс: программа+пользователи+рабочие инструкции) готова к запуску в рабочем режиме
На этом этапе Исполнитель и Заказчик выполняют следующие работы:
Инсталляция рабочей базы данных, рабочих мест
Выполнение необходимых настроек функциональности (например, учетных политик, функциональных опций системы)
Наладка операционного программного обеспечения и технических средств
Выполнение настроек прав доступа
Разработка методик переноса и выверки (нормализации) данных
Разработка, тестирование, выполнение процедур переноса данных
Проверка пользователями результатов переноса, выверка (проверка достоверности) и утверждение Заказчиком результатов переноса (входящих данных)
Разработка проектов регламентов работы пользователей и администраторов (рабочих инструкций). Утверждение проектов регламентов
Разработка программ обучения ключевых пользователей и администраторов. Утверждение программ обучения
Обучение и тестирование ключевых пользователей и администраторов. Тестовые прогоны процессов с участием пользователей на фрагментах реальных данных
Решение прочих организационных вопросов
Важно: Исполнитель, как правило, отвечает за достоверность данных – результатов переноса только в части корректной реализации методик переноса, которые разработал Исполнитель, утвердил Заказчик. таким образом, ответственность за результат переноса разделяется:
- Заказчик отвечает за корректность и соответствие утвержденным форматам исходных данных (подлежащих переносу)
- Исполнитель отвечает за правильность отработки утвержденной методики переноса
Настоящий этап отличается от опытной эксплуатации тем, что результаты работы системы на этом этапе используются для формирования рабочей отчетности и управления предприятием.
- Актуальность данных в системе поддерживаются в режиме реального времени
- Ранее действующие системы автоматизации, функции которой замещены созданной системе ERP, на этом этапе разрешено использовать только для получения исторических данных
- Отчетность разрешено формировать только в ERP-системе
На заключительных стадиях, когда принимается не модель, а настроенная система, как бы тщательно не проверяли функционал, непременно будут появляться новые требования к системе (как объективно - со стороны бизнеса, так и субъективно – со стороны пользователей, для удобства работы). Как правило эти требования можно реализовать в рамках сопровождения. Но бывают и скрытые недостатки, которые нельзя выявить до промышленной эксплуатации. Они могут проявиться в реальной работе спустя месяцы, при особой комбинации ситуаций. Это нормально и устранение таких скрытых недостатков у нас предусмотрено в договоре – по гарантии, которая длится от 9 месяцев до года. Эту работу мы выполняем без оплаты, за наш счет.
Внедрение ERP системы на производственном предприятии является сложнейшей задачей, ERP система является по сути “нервной системой” предприятия, а проект автоматизации можно сравнить с имплантацией этой системы в живой организм.
На проекте приходится решать множество организационных задач, в том числе выделять время руководителей предприятия и пользователей, вырабатывать подчас не очевидные методические решения, “вскрывать” пласты неформализованных процессов, определять как совместить наработки в действующих системах с принципиально новыми методиками внедряемой системы, решать задачи мотивации при увеличении нагрузки на сотрудников и так далее.
Конечно, за ворохом ежедневных реальных проблем не так просто найти время на то, чтобы предотвращать проблемы потенциальные, те, которые еще не случились. Тем не менее, «профилактика эффективней лечения». Важно не только знать риски проекта, важно оценивать их вероятность и последствия. Обязательно нужно планировать действия сторон, направленные на снятие или снижение риска (стратегия управления риском).
Поэтому мы стараемся придерживаться следующей практики.
На подготовительной стадии руководитель проекта просматривает специальный реестр типовых рисков и оценивает, какие из них могут случиться на текущем конкретном проекте. Далее в Уставе проекта он отмечает эти риски и предлагает стратегию работы с ними. Похожий процесс повторяется перед началом каждой стадии. Также еженедельно при составлении оперативного отчета о состоянии проекта Руководитель проекта фиксирует в этом отчете – не возникли ли угрозы еще каких-либо потенциальных проблем. И если возникли – что он собирается предпринимать для того, чтобы их контролировать.
Обсудить ваш проект