Введение в управление проектами внедрения ERP-систем

А. Э. Бобровников (2024)

В книге «Введение в управление проектами внедрения ERP-систем» рассматриваются теория и практика управления проектами внедрения корпоративных информационных систем. Успешный запуск ERP-системы в промышленную эксплуатацию сопряжен с проектом внедрения, идущим несколько месяцев или лет. Как пройти этот путь от начала до конца? Книга дает начальное представление по этим темам. Вопросы внедрения автоматизации иллюстрируются на примере прикладного решения «1C:ERP Управление предприятием». Книга адресована начинающим специалистам, участвующим в проектах внедрения ERP-системы, как на стороне исполнителя, так и заказчика проекта. Студенты и аспиранты могут использовать данное издание для расширения и закрепления полученных знаний в области автоматизации компаний. В формате PDF A4 сохранен издательский макет книги.

Глава 2. Как выбрать ERP-систему

2.1.Функциональные требования от ключевых сотрудников

Вопросам выбора конкретной ERP-системы предшествуют определенные процессы внутри компании: кто-то почему-то хочет ERP-систему. В компании есть группа лиц, заинтересованных в автоматизации своих процессов. Пусть даже это только итоговая финансовая отчетность и вычисление KPI по ней (цели финансового директора), а остальным сотрудникам «ничего от этой ERP не нужно, и так все хорошо». Либо причины иные — зачем ERP-система компании, рассматривалось в первой главе.

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

Проблемы конфликтов в коллективе будут рассмотрены ниже в главе про риски.

С системой предстоит работать разным подразделениям, от которых выделяются ключевые сотрудники (руководители подразделений или продвинутые исполнители бизнес-процессов). Эти специалисты формируют списки своих требований к системе, которые объединяются в общий сводный список требований к функциональности системы или, по-другому, список функциональных требований.

Ключевой сотрудник — это работник, от результатов труда которого зависит эффективная работа компании. Этот специалист четко понимает и выполняет бизнес-процессы внутри своего отдела (или функцию, за которую отвечает или является ее основным исполнителем).

Ключевые требования к ERP-системам:

● функциональность, соответствие уникальным особенностям бизнеса (отраслевая специфика);

● быстродействие, отказоустойчивость, масштабируемость системы;

● инструментарий для мониторинга системы, сбор статистики для анализа факторов, влияющих на быстродействие, аудит работы пользователей;

● возможность и инструментарий доработки функционала;

● разграничение прав доступа к данным и функциям;

● интеграция с существующими системами;

● наличие материалов для обучения пользователей и понятный интерфейс для их работы, предъявление низких требований к уровню квалификации пользователей;

● стоимость приобретения и владения ERP-системой;

● наличие проверенной методики внедрения (тиражирование готового решения).

Требования разделяются на функциональные и нефункциональные. Разница между ними простая: нефункциональные требования — это требования к характеристикам системы, а не к ее функциям. Функциональные требования отвечают на вопрос: «Что должна делать система?»

Критерии, которых нужно придерживаться при формулировании требований к КИС:

● полнота описания;

● правильность, точность и недвусмысленность формулировок;

● осуществимость (можно сделать в принципе);

● необходимость (только нужное, без лишних фантазий: «а давайте еще попросим…»);

● приоритет;

● проверяемость.

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

Можно разделить требования к системе на три уровня:

● Есть глобальные цели автоматизации, которые, как правило, озвучивают спонсоры проекта (собственники бизнеса). Это что-то типа: повысить производительность/оборачиваемость, сократить запасы/издержки и т. д.

● Есть задачи линейных руководителей (снабжение, производство и т. д.), как правило, это какие-то функциональные блоки, глобальные консолидированные отчеты, доп. аналитика.

● Требования рядовых пользователей: интерфейсы, кнопки, отчеты, печатные формы, конкретные рабочие места.

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

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

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

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

2.2.Тендер и участие в нем

2.2.1.Со стороны заказчика

Ну что же, решение о том, что компании нужна ERP-система, принято, начинаем выбирать саму систему и исполнителей для проекта внедрения.

В первой главе рассматривалось заблуждение, что можно ограничиться только самой системой и она запустится «как-то так, сама». Исходим из того, что понимание возможных вариантов ERP-систем, бюджетов и стоимости владения у компании уже есть (какие-то сотрудники представляют, что это такое). Либо такого понимания нет, и его как раз нужно выработать в процессе выбора системы.

Второй случай (нет понимания) нужно приводить к первому. Для этого нанять в штат специалиста, который понимает в автоматизации компаний, — это будущий руководитель проекта внедрения со стороны заказчика, а впоследствии руководитель группы поддержки и развития системы в компании. Вся группа, впрочем, может быть из одного этого специалиста или разрастись до целого отдела. Можно выбрать специалиста с целевыми компетенциями из текущих сотрудников и предложить сменить вид деятельности, карьеру и занять такую интересную вакантную должность. Но нужно учесть, что этот специалист должен иметь опыт или профильное образование для соответствия задачам внедрения проекта автоматизации. Итак, с помощью Интернета, знакомых коллег из других компаний отрасли получено первичное представление о мире ERP-систем: какие системы бывают, кто основные игроки на рынке (кто их производит, кто внедряет). Например, по 1С: ERP много информации предоставлено в открытом доступе на официальном сайте продукта http://v8.1c.ru/erp/. Составляется шорт-лист систем и их потенциальных поставщиков. Компании, туда попавшие, могут быть как крупными, известными на рынке, так и мелкими, но по рекомендации знакомых.

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

Далее нужно составить документ (несколько документов) из серии RFx:

● RFI — запрос информации (англ. Request For Information);

● RFP — запрос на предложение (англ. Request For Proposal);

● RFQ — запрос о цене (разрабатываемой системы) (англ. Request For Quotation).

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

Цель документа — собрать письменную информацию о возможностях различных поставщиков. Как правило, запрос предполагает заполнение таблички опросника в определенном формате, благодаря чему ответы от разных поставщиков по шаблону могут использоваться для сравнения информации. RFI редко является заключительным этапом, часто используется в комбинации с запросом предложения (RFP) и запросом цены (RFQ).

Компании, проявившие интерес, и составят круг участников тендера на проект автоматизации.

Если уже ясно, какая ERP-система нужна (а такое бывает, т. к. определяется, например, стоимостью самой системы или поддержкой отраслевой специфики), то выбор самой системы уже ясен, и проводится выбор исполнителя для проекта автоматизации.

Конец ознакомительного фрагмента.