Бизнес план внедрения автоматизированной системы
VII Детализируем процессы, включенные в рамки проекта
Нужно усложнять, чтобы в результате все стало проще,
а не упрощать, чтобы в результате все стало сложнее.
Веслав Брудзиньский
Определив основные функции и рамки проекта, можно переходить к детальному описанию алгоритмов функционирования, создаваемой системы. В этом блоке работ мы используем прием, позволяющий «попутно» определить связи между процессами и хранилищами. Это поможет нам плавно перейти от моделей процессов к моделям данных.
Цель данной группы работ: на основании выявленных функций, определить сценарии использования, разрабатываемого целевого продукта.
Для подобных целей удобно использовать графические изображения бизнес процессов при помощи алгоритмических диаграмм (деловое моделирование). Алгоритмизация – это еще один прием дисциплины «Системный анализ».
Дополнительный бонус от использования диаграмм бизнес процессов, заключается в том, что они исключительно полезны при разработке приемочных тестов. Ну об этом чуть позже.
На рисунке 7.1 изображен процесс формализации требований к целевой системе, дополненный подпроцессом определения сценариев ее использования.
Рисунок 7.1 — модель процесса определения сценариев использования системы
К алгоритмическим диаграммам, описывающим процессы предъявляют следующие требования:
- они должны достаточно подробно и точно описывать логику процесса. Настолько подробно и точно, насколько это нужно в каждом конкретном случае.
- они должны быть одинаково понятны различными группами заинтересованных лиц проекта. Это, в первую очередь, люди бизнеса, чью работу они описывают, а также исполнители: бизнес-аналитики, разработчики и т.п.
Диаграммы бизнес процессов основаны на канонических нотациях Activity (диаграммы деятельности), но имеют дополнительные особенности, о которых я поведаю в этой главе.
1. Используем диаграммы бизнес-процессов
Хочу уточнить, что в данном разделе мы взглянем на предметную область под иным углом и будем рассматривать описание не любых процессов, а именно процессов «уровня бизнеса», которые:
- хорошо понятны заказчику (конечным пользователям разрабатываемого целевого продукта);
- оперируют понятиями предметной области заказчика («документ», «задача», «план» и т.п.);
Процессы на диаграммах желательно разбивать на бизнес транзакции (business transaction) см. рис.7.2, что позволит получить список основных сценариев – возможностей, которыми должен обладать целевой продукт, для его согласования с заказчиком, а также, для обсуждения полноты и логики процессов. То есть каждая бизнес транзакция на диаграмме, должна соответствовать одной конечной операции, представленной в виде сценария использования системы пользователем.
На рисунке 7.2 приведен пример контейнера диаграмм, группирующий диаграммы процессов, разбитые по бизнес транзакциям.
Рисунок 7.2 – Деление процессов на бизнес транзакции
Как на любой диаграмме деятельности, должно быть указано начало процесса и его окончание (варианты завершения). Например на рис. 7.4 представлено два варианта завершения процесса «Потребность зафиксирована» или «Потребность отклонена». Но в отличие от канонической диаграммы, на диаграммах данного типа, процесс может начинаться с нескольких событий, см. рис.7.3
Рисунок 7.3 – Фрагмент диаграммы с 2_умя точками входа в процесс
В качестве примера опишем более подробно процесс «А1.1 Сбор потребностей заказчика» выявленный нами на предыдущем этапе. Обратите внимание, что на каждом последующем шаге, мы используем результат (продукт) предыдущего шага. На рисунке 7.4 изображена диаграмма, описывающая бизнес процесс сбора потребностей заказчика. В отличие от диаграмм IDEFO, диаграмма бизнес процессов позволяет моделировать условные переходы, что критично для описывания алгоритмов функционирования: «Если выполняется условие – делаем то-то, иначе следующее». На диаграммах данного типа можно указывать исполнителей, а также ресурсы, используемые системой. Например – хранилища.
Рис. 7.4 – Диаграмма Бизнес процесса Сбор потребностей заказчика
Несмотря на то, что мы рассматриваем процессы, связанные с бизнес составляющей разрабатываемого программного продукта, на диаграмме можно выделить и системные элементы. Например, на рис.7.4 отмечено — хранилище «Пользовательские истории», которое используется для:
- выборки данных, с целью анализа корректности, регистрируемой в системе Пользовательской истории;
- непосредственно для регистрации в системе новой верифицированной Пользовательской истории.
Стрелками (на рис.7.4 они отображены пунктирными линиями) можно отобразить передачу данных в хранилище при выполнении процесса, указав какие конкретно типы данных передаются, а также типы данных вычитываемые из хранилища, в результате выполнения других процессов. Таким образом, мы фиксируем: в каких процессах, какое хранилище используется и какими при этом бизнес данными обменивается система с пользователем.
2. Пример использования диаграммы бизнес-процессов для определения ролей и хранилищ данных
Давайте рассмотрим еще один, более сложный пример описания бизнес процесса. На рисунке 7.5 изображена диаграмма, моделирующая процесс Обработки обращений заинтересованных лиц.
Рис. 7.5 – Диаграмма Бизнес процесса Обработка обращений заинтересованных лиц
Еще один плюс диаграмм данного типа, это возможность выявлять потребителей, инициаторов, исполнителей процесса, позволяющая на ранних стадиях проектирования выделить роли пользователей целевого продукта и набросать набор функций для них. Для этого каждый процесс связан (стрелкой) с исполнителем: пользователем (ролью) или системой.
И это еще не все. На диаграмме, как мы уже отмечали раньше, видно (по направлению стрелок), как одни процессы выполняют запись в хранилища, а другие производят выборку данных из них. А это, еще одна полезная функция использования диаграмм сего типа — определение всех «точек» обращения к хранилищам для выборки и записи данных. Анализ этих процессов позволяет оптимизировать их, для минимизации возникновения взаимных блокировок записей в базе данных.
Например, на рис. 7.6 Хранилище «Элементы архитектуры», может использоваться в нескольких бизнес транзакциях и в нескольких процессах.
Рис. 7.6 – Использование диаграммы для формализации хранилищ
В результате мы можем получить таблицу зависимостей хранилища, собранную по всем диаграммам, где оно используется, см. рис.7.7.
Рис. 7.7 – Таблица зависимостей ресурса
Диаграммы Бизнес процессов, также помогут нам для определения противоречий в функциях, изменяющих данные в хранилищах. Иными совами: проверка непротиворечивости требований. Таким образом, происходит последовательное детальное описание всех процессов, реализующих функции, выявленные на предыдущей стадии моделирования, и определение их взаимосвязей с моделью структуры хранилищ данных. Нечто подобное используется в методологии ICONIX, только там за основу взяты диаграммы последовательностей.
3. Используем диаграммы бизнес-процессов для реинжениринга
Моделируя бизнес процессы, существующие у заказчика при помощи диаграмм, зачастую можно натолкнуться на следующие проблемы:
- дублирование функций различными подразделениями;
- неэффективное распределение обязанностей между исполнителями;
- процессы, производящие невостребованные продукты;
- «провисание» зон ответственности на стыке процессов;
- пересечение полномочий в процессах и т.д.
В таких случаях диаграммы могут стать отправной точкой в обсуждении с представителями заказчика вопросов оптимизации или реинжиниринга бизнес процессов. Крайне важно суметь убедить сторону заказчика не выполнять автоматизацию тех процессов, которые существуют, а разработать и автоматизировать новые «правильные» процессы. Но при этом, не стоит утаивать связанные с этим проблемы, как минимум такие как: «ломка» сложившихся на предприятии устоев и необходимость какое-то время, при внедрении системы, поддерживать и старые и новые бизнес процессы. Возможно, Вы примите какой-то третий, временный вариант, который позволит смягчить переход и минимизировать неудобства.
Для наглядного убеждения заказчика в необходимости менять процессы, можно разработать систему ключевых показателей этих процессов, позволяющую количественно оценить эффект от их замены. Измерять можно как эффективность самого процесса, так и продукта, производимого процессом.
Презентовать подобные исследования лучше в виде сравнительных таблиц. В качестве колонок обозначаем процессы: текущий и целевой или несколько вариантов целевого. В качестве строк — утвержденные показатели. На пересечении заполняются значения показателя для процесса.
Например, таблица сравнительного анализа может выглядеть так:
Формирование таких показателей и определение их значений, должно производиться при непосредственном участии представителей заказчика. Количество показателей не должно превышать 20.
4. Просчитываем предварительную ркусрсоемкость проекта
Рассматриваемый нами в этой главе тип диаграмм имеет еще одно очень существенное достоинство. На основании их можно довольно точно оценить предварительную трудоемкость процесса разработки целевого продукта. Если на каждом элементе диаграммы подписать стереотип, например: «Форма списка», «Форма карточки», «Функция», «Отчет» и т.д., то легко подсчитать количество элементов, которые необходимо реализовать. Трудоемкость реализации каждого типа элемента, при использовании устоявшихся в команде технологий, в общем известна. Для повышения точности можно использовать коэффициент сложности.
Например, таблица предварительного расчета трудоемкости может выглядеть так:
Для удобства, коэффициенты могут использоваться трех типов “сложный”, “средний” и “простой” и для каждого типа элементов иметь свои значения. Например:
- для Сущностей: 0,3 — простой; 0,7 — средний; 1 – сложный;
- для Выборки: 1 — простой; 1,5 — средний; 2 – сложный;
- для Форм: 0,7 — простой; 1,5 — средний; 2 – сложный;
- для Процедур: 1 — простой; 3 — средний; 6 – сложный;
- для Отчетов: 0,5 — простой; 1 — средний; 3 – сложный;
Разработав на начальной стадии подобную таблицу, ею можно пользоваться и в дальнейшем на протяжении проектирования, внося в нее изменения при уточнении и доработке требований. Это очень эффектно, когда “легким движением руки” аналитик предоставляет менеджеру проекта обновленные и уточненные прогнозы ресурсных затрат для свежих, только что доработанных требований.
5. Пересматриваем границы проекта (при необходимости)
В предыдущей главе, мы говорили о границах проекта и о том, что они могут меняться. Например, в рассматриваемом нами проекте, после уточнения перечня процессов, мы видим, что упустили одну из самых важных функций, а именно коммуникацию в команде. Для сбора и обсуждения потребностей заказчика, необходимо организовывать совещания, митинги, дискуссии и т.п., Следовательно, мы должны запроектировать блок функций, поддерживающих управление коммуникациями с заинтересованными лицами.
На диаграмме функциональной модели системы, рассмотренной в прошлой главе, мы добавили новый процесс: «Управление совещаниями» см. Рисунок 7.8, он выделен сиреневым цветом.
На вход процессу поступает информация о реализации ранее сформулированных требований, а результатом выполнения функций могут стать планы проведения совещаний, итераций и т.п., Например, этот модуль может рассылать письма приглашенным участникам с информацией о совещаниях.
Рис. 7.8 – Изменения в функциональной модели системы Управления требованиями
6. Подведем итоги использования процессных моделей
На этапе детального уточнения функций системы и сценариев ее использования, часто возникает ощущение потери нити понимания того, как же всё-таки должна работать система. Не стоит этого бояться и отчаиваться. Продолжайте уточнять требования и переосмысливать начальное представление о системе – это нормально. Постепенно все само встанет на свои места.
Итак, после того как мы получим полный набор описания бизнес сценариев, предназначенных для автоматизации и предварительную структуру хранилищ данных, можно переходить к разработке модели данных. На самом деле, диаграммы этого типа можно начинать строить и раньше, параллельно с описанием процессов, но все же, основная часть этих работ должна производиться уже после идентификации всех бизнес функций.
В моей практике был проект, в котором при помощи высшего руководства, диаграммы делового моделирования были популяризированы среди среднего звена менеджмента. Люди втянулись и уже активно соревновались друг с другом в умении их использовать. Это стало не только модно, но и очень полезно, при обсуждении текущих деловых процессов, а также моделировании новых.
Для лучшего понимания необходимости использования диаграмм Бизнес процессов, можно провести аналогию с географическими картами. Все те же преимущества, которые мы получаем от использования карт местности, для того чтобы выбрать оптимальный путь между пунктами назначения, можно получить от диаграмм бизнес процессов, которые служат картами продвижения процесса и преобразования его ресурсов в запланированный результат (продукт).
Эту аналогию желательно донести до всех участников проекта. Идеальный вариант, свидетельствующий о качестве подготовленных диаграмм и грамотной их презентации всем заинтересованным лицам, выглядит как митинг членов команды, сгрудившихся над диаграммами и водящим по ним указками, подобно генералам, склонившимся над стратегическими картами наступлений. Развивая аналогии дальше, вышеупомянутые диаграммы IDEFO, можно сравнить с Атласами карт, группирующими их по областям (в данном случае — предметным).
В следующей части мы будем выявлять сущности предметной области ссылка.
Список литературы
1. Якобсон А., Буч Г., Рамбо Дж. – «Унифицированный процесс разработки ПО» (2004)
2. Дэвид А. Марк и Клемент МакГоуэн – «Методология структурного анализа и проектирования SADT»
3. Коберн — «Современные методы описания функциональных требований» (2002)
4. Леффингуэлл Дин, Уидрих Дон — «Принципы работы с требованиями к ПО» (2002)
5. Карл И. Вигерс – «Разработка требований к программному обеспечению» (2002)
6. Элизабет Халл, Кен Джексон, Джереми Дик — «Разработка и управление требованиями практическое руководство пользователей» (2005)
7. Скотт Амблер – «Гибкие технологии: экстремальное программирование и унифицированный процесс разработки» (2005)
8. Гринфилд Джек, Кейн Шорт — «Фабрики разработки программ» (2007)
9. Алистэр Коуберн — «Каждому проекту своя методология»
10. Вольфсон Борис- «Гибкие методологии разработки»
11. Лешек А. — «Анализ требований и проектирование систем»
12. Фримен Эрик, Фримен Элизабет — «Паттерны проектирования» (2011)
13. Эванс Эрик — «Предметно-ориентированное Проектирование» (2011)
14. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»
Источник
Вопросы, рассмотренные в материале:
- Что такое система ERP?
- В чем плюсы и минусы системы ERP?
- Из каких этапов состоит план внедрения системы ERP?
В современном обиходе не существует единого понятия «ERP-системы», поскольку данную аббревиатуру довольно часто используют для обозначения разных по своей сути интегрированных информационных структур. Дословно ERPS (Enterprise Resource Planning System) переводится как «система планирования ресурсов предприятия». Ее прямое предназначение заключается в автоматизации учета и управления корпоративными ресурсами организации. О том, как разработать грамотный план внедрения системы ERP, вы узнаете из нашей статьи.
Что такое система ERP
Для того чтобы понять суть ERP-системы и осознать необходимость разработки плана для ее внедрения, недостаточно просто иметь представление о расшифровке аббревиатуры и ее переводе на русский язык, в идеале нужно изучить историю происхождения данного понятия.
Конец XX века ознаменовался массовой автоматизацией различных бизнес-процессов: распространение компьютеров повлекло за собой активную разработку программ ведения финансового и бухгалтерского учета, электронного документооборота, проверки функционирования техники и оборудования. Автоматизация бизнеса позволила оцифровать всю имеющуюся информацию, внедрить новые методы проведения анализа и обмена сведениями, а также объединить данные разных типов.
То есть благодаря компьютеризации появились новые рычаги управления и контроля над процессами, происходящими на предприятии, а также возможность анализа результатов работы по отдельным направлениям (бухгалтерии, склада, основного производства и т. д.) или всей организации в целом.
Результаты автоматизированного анализа способствовали более грамотному распределению производственных мощностей и последующему принятию оптимальных решений для развития бизнеса. Методику ведения бизнеса с применением различных автоматизированных программ управления ресурсами предприятия назвали ERP, а программное обеспечение, используемое в этих целях, – ERP-системой. То есть все компьютерные программы, предназначенные для работы бухгалтерии, управления персоналом и т. д., являются частями системы ERP, при этом CRM (customer relationship management system) тоже относится к ERP и переводится как «система управления взаимоотношениями с клиентами».
Стоит отметить, что система ERP стала результатом развития более простых концепций: MRP (Material Requirement Planning – планирование материальных потребностей) и MRP II (Manufacturing Resource Planning – планирование производственных ресурсов). Внедрение программного обеспечения систем ERP позволяет осуществлять производственное планирование, моделировать поток заказов и оценивать возможность их реализации в службах и подразделениях подчиненной организации.
Возможности большинства систем ERP позволяют охватить все основные направления деятельности предприятия.
Перед тем как приобрести и внедрить информационную систему в деятельность своей организации, следует точно определиться с целью покупки и понять, какой вариант программного обеспечения требуется вашему бизнесу: система класса ERP либо учетная система. Помните о том, что система ERP предназначена в первую очередь для составления планов оптимального использования ресурсов предприятия. Программы ERP-системы помогут вам ответить не только на вопросы «как было» и «как есть», но и «как будет», «как должно быть».
Внедрение системы ERP позволит не только производить учет текущих сведений, но и разрабатывать планы по моделированию и оптимизации использования всех видов ресурсов организации (финансовых, материальных, человеческих, временных и так далее). Большая часть программных функций системы направлена именно на достижение вышеперечисленных целей.
Что касается учетной системы, с ее помощью можно осуществлять только фиксацию результатов. В отличие от систем ERP, учетные программы не оснащены функциями автоматизации планирования и не позволяют сравнивать текущие результаты работы с прогнозируемыми показателями. То есть учетные системы имеют ограниченные возможности управления организацией в части, касаемой планирования и оптимизации использования ресурсов предприятия.
Плюсы и минусы системы ERP
Реализация плана по внедрению системы ERP обязательно изменит качество ведения вашего бизнеса. Одним из самых важных преимуществ является рациональное распределение работы между подразделениями организации, что позволяет сократить затраты на дублирование функционала и другие возможные расходы, связанные с отсутствием единой системы управления компанией.
Помимо этого среди преимуществ внедрения системы ERP следует выделить:
- Синхронизацию процессов. Благодаря внедрению системы ERP вы сможете упорядочить получение данных и обмен ими на всех взаимосвязанных между собой этапах деятельности организации. Это в свою очередь положительно скажется на эффективности работы каждого подразделения, ведь именно от совокупности результатов зависит общая картина продуктивности производственных процессов.
- Контроль процессов. Внедрение системы ERP позволяет контролировать буквально все рабочие процессы, протекающие в подчиненной организации: начиная от самых простых оперативных функций и заканчивая стратегическим регулированием деятельности всего предприятия.
- Унификацию отчетности. При помощи программного обеспечения ERP все финансовые и статистические отчеты выводятся согласно единому образцу, что значительно облегчает совокупный анализ текущих результатов работы отделов организации.
- Стандартизацию информационных систем. Применение всех модулей системы ERP исключает необходимость установки и обслуживания других компьютерных программ и информационных систем.
- Расширенный спектр руководящих функций. Внедрение системы ERP позволяет активно пользоваться базами управления корпоративными знаниями компании, увеличивая функциональность руководителя.
- Интеграция с контрагентами. Некоторые ERP-системы предусматривают возможность участия клиентов организации. К примеру, они могут самостоятельно формировать заказ, отслеживать его статус, анализировать наличие материальных запасов, пополнять их в случае необходимости и т. д.
- Приспособление к потребностям предприятия. Внедрения системы ERP может быть полным или частичным, поскольку ее модули работают как автономно, так и в совокупности со всей системой. Выбор проекта должен осуществляться исходя из потребностей конкретного предприятия.
- Защиту данных. Администратор может категорировать всех пользователей системы ERP, предоставив каждой категории доступ к определенным ресурсам и функциям. Но при этом действия каждого пользователя можно будет легко отследить и проверить.
- Централизацию информации. Внедрение системы ERP позволяет хранить все данные организации в одном месте, благодаря чему в случае необходимости всегда можно будет получить нужные сведения.
- Интеграцию с другими системами. В случае применения API-интерфейса ERP-системы могут взаимодействовать с системами более низкого уровня, такими как технологическое оборудование, производственные комплексы и станки.
- Повышение эффективности взаимодействия. Внедрение системы ERP предусматривает наглядную демонстрацию результатов работы каждого подразделения, что помогает улучшить взаимодействие между ними.
- Масштабирование. Разработка и внедрение ERP-системы особенно актуальна для компаний, имеющих представительства в других регионах, поскольку ее модули позволяют наладить централизованное управление и масштабировать принимаемые решения.
- Обеспечение контроля в смежных направлениях. ERP-системы являются совокупностью программ с различным функционалом, что помогает контролировать все сферы деятельности компании: отслеживать статусы заказов, показатели материального обеспечения, финансовые потоки и другие параметры по основным направлениям работы предприятия.
Но, несмотря на все вышеперечисленные достоинства, систему ERP нельзя назвать совершенной, поскольку она имеет и некоторые отрицательные моменты:
- Длительная установка. Исполнение плана по внедрению системы ERP в крупную корпорацию может длиться от полугода до трех. При этом до окончательной реализации программы установки всех модулей некоторые из них могут работать некорректно.
- Высокая стоимость. Итоговая стоимость системы ERP складывается из нескольких ценовых факторов: программного обеспечения, сопутствующего технического оборудования, а также проведения работ по установке, настройке, проверке и дальнейшему обслуживанию.
- Сложности использования. Максимально эффективное применение модулей системы возможно только после всестороннего обучения сотрудников, поскольку рассматриваемое программное обеспечение имеет довольно сложный интерфейс.
- Уровень соответствия ПО деятельности компании. Слишком маленькое количество настроек в программе не позволит привести ее в точное соответствие с деятельностью организации, а при наличии большого количества настроек может возникнуть острая необходимость доработки и внесения корректировок.
- Дополнительные затраты. После внедрения системы ERP, она потребует систематического обновления программного обеспечения, оборудования и связных каналов, что напрямую связано с дополнительными финансовыми вложениями.
- Перенос информации. Стоит отметить, что при внедрении системы ERP в деятельность предприятия нередко возникают дополнительные затраты с переносом информации из программ, которые использовались организацией ранее.
Пошаговый план внедрения ERP-системы
План внедрения системы ERP можно условно поделить на семь основных частей: организационные работы, обследование организации, выбор методологии, проектирование системы, установка программ на рабочих местах, запуск системы в эксплуатацию и сопровождение.
- Организационный этап.
С чего же начать внедрение ERP системы на предприятии? Введение ее должно начинаться с определения основных целей и задач. Не стоит проводить автоматизацию ради автоматизации – заказчик должен иметь четкое представление о желаемых результатах.
Организационный этап также включает в себя создание рабочей группы на предприятии. Как правило, в ее состав входят:
- Руководитель (его лучше выбирать среди топ-менеджеров организации). Он должен быть осведомлен обо всех бизнес-процессах, протекающих на предприятии. Помимо этого, у руководителя проекта внедрения системы ERP должны быть полномочия по единоличному принятию решений по любым вопросам.
- Специалисты, контролирующие соответствие внедряемой системы актуальным нормативно-правовым актам и корпоративным стандартам. Это могут быть: исполнительный директор, главный бухгалтер или начальник IT-службы.
- Начальники всех подразделений, которые в дальнейшем будут пользоваться новым программным обеспечением. Они должны будут консультировать специалистов по внедрению в ходе изучения последними бизнес-процессов предприятия, а также организовывать работу подчиненных сотрудников после завершения автоматизации.
- IT-специалист широкого профиля. Его основной задачей будет техническое сопровождение плана по внедрению системы ERP.
Стоит отметить, что план внедрения системы ERP будет работать на полную мощность только в том случае, если программным обеспечением будут максимально активно и эффективно пользоваться все сотрудники организации. Для этого работников нужно обучить основным правилам пользования ERP и строго контролировать действия персонала на начальном этапе эксплуатации программы. Ответственными за обучение подчиненных и корректировку их действий также являются члены рабочей группы.
Плюс ко всему, на организационном этапе нужно определиться с источниками финансирования и выбрать компанию-интегратора.
- Этап обследования предприятия.
После окончания организационных мероприятий наступает следующий этап плана – изучение и анализ основных бизнес-процессов компании. Это нужно для того, чтобы точно определить сроки и стоимость работ по внедрению системы ERP. Ориентируясь на масштабы предстоящих работ и поставленные цели, IT-интегратор предлагает заказчику два плана по обследованию предприятия:
- Экспресс-обследование. Занимает от 1,5 до 2 месяцев. Результатом обследования является «Предпроектный анализ», в котором описываются все нюансы автоматизированного учета и перечень задач, подлежащих решению в ходе внедрения.
- Полное обследование. Длится на протяжении 3–5 месяцев. В результате тщательного обследования формируется «Техническое задание», готовятся бизнес-процессы автоматизированного учета, а также указывается перечень необходимых корректировок программного обеспечения.
Выбор конкретного плана обследования зависит в первую очередь от методологии внедрения ERP.
- Выбор методологии внедрения ERP.
Существует четыре основных варианта внедрения ERP-решений на платформе «1С: Предприятие»:
- Абонентское time and material. IT-интегратором проводится экспресс-обследование организации, формируется план проекта внедрения ERP-системы и рассчитывается максимально возможная стоимость работ. Данная цифра прописывается в договоре, так же как и стоимость одного часа работы специалиста, интегрирующего программу.
План работ по внедрению системы ERP разбивается на несколько месяцев. В зависимости от общего объема рабочих часов определяется количество ежемесячных затрат. Фиксированный размер платежа также отражается в соглашении между компаниями.
- Поэтапная технология внедрения. Подразумевает полное обследование предприятия и определение всех автоматизируемых бизнес-процессов с последующей разработкой технического задания. В ТЗ указывается: количество необходимых доработок, развернутый план работ с разбивкой на этапы, сроки и стоимость проведения каждого этапа внедрения системы ERP. Существенный недостаток данной технологии заключается в отсутствии гибкости, то есть внесение даже самых незначительных изменений в план работ повлечет за собой корректировку ТЗ, сроков и итоговой стоимости.
- Технология быстрого результата. План внедрения ERP-системы на предприятии в данном случае схож с примером абонентского обслуживания: на основании экспресс-обследования осуществляется расчет максимальной стоимости работ по внедрению и оценивается час работы IT-специалиста. Работы по внедрению системы ERP оплачиваются заказчиком также раз в месяц, но исходя из реального количества затраченных программистами часов.
Данная методология не предусматривает составления четких планов работ на неделю или месяц, перечень и очередность выполнения задач определяется актуальными потребностями организации. То есть главное достоинство технологии быстрого результата – в ее гибкости. Изменения вносятся в план внедрения системы ERP без длительных согласований. К числу минусов методологии относят отсутствие возможности определения точных сроков внедрения ПО.
- Проектирование системы ERP.
После обследования организации программисты определяют основные требования к базовым модулям ERP-системы, необходимость загрузки начальных данных, а также параметры настройки для перемещения сведений из используемых организацией программ. Модули системы программируются в соответствии с основными бизнес-процессами компании; в функционал программного обеспечения вносятся необходимые корректировки.
- Внедрение ERP-системы на предприятии.
Согласно плану внедрения на данном этапе осуществляется установка программ ERP-системы на рабочие места персонала. Производится настройка прав доступа и отчетов. Загружаются данные из ранее используемых предприятием компьютерных программ.
- Запуск системы в эксплуатацию.
После окончания процессов автоматизации проводится обучение пользователей, а также осуществляется разработка инструкций по работе в системе.
- Сопровождение внедренной системы.
Бесперебойная работа ERP-системы на платформе «1С: Предприятие» возможна при условии поддержки после внедрения.
Источник