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

? Хотим ли мы всем управлять и менять систему гибко, как нужно нам для наших устоявшихся бизнес-процессов.

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

И в зависимости от этого выбрать тот или иной способ и определить (заранее) стоимость владения ERP-системой.

Подробнее об облачных технологиях компании «1С» можно почитать здесь:

http://v8.1c.ru/overview/Term_000000803.htm (http://v8.1c.ru/overview/Term_000000803.htm)

Рис. 1.7. Облачный сервис компании «1С»

Система 1C: ERP присутствует в облачном сервисе «1С: Предприятие 8 через Интернет» по модели SaaS. Подробнее об этом – по ссылке: https://1cfresh.com/solutions/erp (https://1cfresh.com/solutions/erp).

Нужно отметить момент резервного копирования информации и выбора поставщика услуги облачного сервиса. Все поставщики услуг обычно пишут на своих сайтах общие слова о гарантии работы 24/7, резервных копиях и о том, что «вам ни о чем не нужно думать, кроме самих данных и работы с ними». Но на практике это могут оказаться рекламные слова. Базу можно потерять безвозвратно. Нужно уточнить правила создания резервных копий, с какой глубиной они хранятся, сколько времени нужно на восстановление по запросу.

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

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

Глава 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/ (http://v8.1c.ru/erp/). Составляется шорт-лист систем и их потенциальных поставщиков. Компании, туда попавшие, могут быть как крупными, известными на рынке, так и мелкими, но по рекомендации знакомых.

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