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

1.1.Понятие ERP-системы

Сам термин ERP – это аббревиатура из английских слов Enterprise Resource Planning, дословно «планирование ресурсов предприятия». Такие системы (и сам термин) были наследием систем MRP и MRP II класса (англ. Material Requirements Planning – планирование потребности в материалах). Но за счет включения в себя множества других модулей или подсистем (тоже имеющих устоявшиеся двух-трехбуквенные обозначения) ERP стало собирательным наименованием систем планирования, учета, управления и принятия решений.

Методология MRP берет начало в 1950-х годах в США, но, формализованная на бумаге, до середины 1970-х отклика в реальном бизнесе не находит, пока компьютерная техника достаточно не эволюционирует. В СССР в середине 1960-х тоже был интересный проект автоматизации народного хозяйства в единой (сетевой по всей стране) компьютерной системе, но техническое воплощение не соответствовало этим опережающим время идеям. Какие-то наработки в 1980-х на Западе пошли в дело и вернулись к нам обратно в виде готовых систем автоматизации в конце 1990-х годов.

ERP-система – это корпоративная информационная система, предназначенная для автоматизации основных бизнес-процессов компании, учета и управления (планирование, контроль и анализ) ресурсами.

Определение термина ERP, которое дает APICS (American Production & Inventory Control Society, Американское общество управления производством и распределением материалов): Планирование ресурсов предприятия (ERP) – это рамки, основа (framework) для организации определения и стандартизации бизнес-процессов, необходимых для эффективного планирования и контроля организации таким образом, чтобы организация могла использовать внутренние знания для поиска внешнего преимущества.

Интересно отметить, что до 2005 года определение от APICS было совсем другим: ERP-система – это финансово-ориентированная информационная система, служащая для определения и планирования ресурсов всего предприятия, требуемых для получения, изготовления, отгрузки и учета заказов потребителей.

Ниже представлен неисчерпывающий перечень систем (и методологий), которые могут входить в состав комплексной ERP-системы как платформы или быть отдельными системами, использующими/предоставляющими данные из/в ERP. Забегая вперед, можно отметить, что на описываемые ниже методики управления проектами внедрения это не сильно влияет – системы внедряются, по сути, по общим методологиям, хотя функциональность и покрываемые бизнес-процессы в них, конечно, разные, есть своя специфика, но все это класс ИТ-проектов внедрения систем автоматизации.

Общепринятые обозначения некоторых систем и понятий:

● MES (Manufacturing Execution System) – производственные управляющие системы;

● WMS (Warehouse Management System) – системы управления складами;

● CRM (Customer Relationship Management) – системы управления взаимоотношениями с клиентами;

● SCM (Supply Chain Management) – системы управления цепочками поставок;

● TMS (Transportation Management System) – системы управления транспортировками;

● PDM (Product Data Management) – системы управления данными о продуктах (изделиях);

● KPI (Key Performance Indicators) – ключевые показатели эффективности. Входят во многие системы показателей, например, BSC (Balanced Scorecard) – сбалансированная система показателей. Объединяются в отдельный блок (подсистему) визуализации показателей (монитор/витрина целевых показателей);

● EAM (Enterprise Asset Management) – управление основными фондами предприятия (процессами эксплуатации и ремонта). ТОиР – техническое обслуживание и ремонт;

● HRM (Human Resources Management) – управление персоналом;

● CPM (Corporate Performance Management) – система управления эффективностью предприятия. Синонимы для такого класса систем: BPM (Business Performance Management), EPM (Enterprise Performance Management), SEM (Strategic Enterprise Management);

● MDM (Master Data Management) – системы управления мастер-данными (сведение и управление общей НСИ – нормативно-справочной информацией);

● BPMS (Business Process Management System) – системы управления бизнес-процессами.

Схема подсистем 1C: ERP представлена ниже на рисунке.

Рис. 1.1. Схема подсистем 1C: ERP

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

Рис. 1.2. Панель разделов 1C: ERP

В ERP-системах от других производителей состав подсистем примерно такой же, но они могут быть как единой системой, так и отдельными системами, интегрированными друг с другом.

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

1.2.Отличие ERP-системы от учетной бухгалтерской системы

Самое важное и определяющее все остальные различия в системах – это целевая аудитория: кто и зачем работает в системе.

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

Современные бухгалтерские системы имеют функциональность для организации контура оперативного учета в компании, но исторически в них часто работают только бухгалтеры. А задачи планирования и оперативного учета остаются «за бортом», менеджеры работают в «эксельках» и «вордах», наклеивают стикеры на монитор с напоминалками или используют для этого календарь и заметки в смартфоне, все бизнес-процессы идут через корпоративную (или бесплатную от известных брендов) почту либо в мессенджерах. Реальные отчеты для управления, планирования, анализа целевых показателей и их достижения по периодам делаются вручную по таким менеджерским базам + выгрузкам отчетов из бухгалтерской системы.

В самой бухгалтерской программе – красота и порядок, наведенный главным бухгалтером компании. Все бухгалтеры работают с понятными учетными функциями, которые проходят в профильных институтах и на курсах бухгалтеров, для всего есть положения по бухгалтерскому учету (ПБУ) и налоговый кодекс (НК) с набором писем Минфина по уточнению трактовок (для уточнения нововведений законодательства).

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

Рис. 1.3. Уровни данных в ERP-системе

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

Ситуация потери монополии на работу в системе (и ее непринятие бухгалтерией), кстати, одно из конфликтных мест при внедрении. Об этом поговорим подробнее в других главах.

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

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

Нужно договариваться, сводить все к единой НСИ. Иначе будет «лебедь, рак и щука» – кто куда, по своим интересам.

А еще могут свое влияние и требования привнести специалисты, составляющие отчетность по международным стандартам (МСФО). Там есть свои стандарты, накладывающие требования по детализации аналитики учета для составления комплекта отчетности и примечаний к нему. Ведение управленческого учета по МСФО очень полезно для менеджмента компании, так как дает им отчетность по принятым мировым методикам именно для целей оценки бизнеса по единым правилам (сопоставимость отчетности с другими компаниями отрасли и конкурентами). Современное образование и особенно MBA (Master of Business Administration) привили новому поколению руководителей компаний навыки работы с показателями отчетности на базе единых мировых стандартов, потому для управленческого учета в качестве корпоративных стандартов часто выбирают МСФО (а не изобретают свой «велосипед» для правил составления корпоративной отчетности).

Некоторые операции в национальном бухгалтерском (и налоговом) учете и в МСФО трактуются сильно по-разному: относятся на разные даты (и даже периоды), разными суммами, по разным статьям. В итоге финансовый результат по периоду может отличаться в разных учетах. Например, по РСБУ компания в прибыли и платит налоги, тогда как по МСФО у компании многомиллионные убытки. И пора бить тревогу, принимая своевременные управленческие решения.

Нужно отметить, что отчетность по МСФО может формироваться по данным бухгалтерской учетной системы, именно ERP для этого не требуется. Но такая отчетность строится обычно перекладкой РСБУ-отчетности (трансформацией) в МСФО-отчетность.

Процедура получения МСФО-отчетности трудоемкая, делается после сведения РСБУ-отчетности и для анализа на стол менеджмента, заинтересованных инвесторов и учредителей ложится сильно позже, чем хотелось бы. Например, в апреле – мае публикуется отчетность за прошедший год, до процесса аудита отчетность для внутренних нужд готова где-то в марте. По такой отчетности повлиять на финансовый результат прошедшего года уже нельзя, это «посмертная отчетность», показывающая свершившийся факт. Принимать решения по ней можно только для исправления будущих периодов. Сокращение сроков подготовки отчетности с годовой до квартальной или месячной требует уже автоматизации и формирования МСФО-отчетов не только по данным РСБУ-отчетности, но и по оперативному учету. Возможно, вообще независимо от РСБУ, со своими сроками закрытия периодов. Тогда отчетность становится оперативной, позволяющей управлять компанией в реальном времени.

Альтернатива МСФО, когда международные стандарты не используются, – оперативный учет, и управленческие отчеты по нему ведутся по корпоративным стандартам с достаточной аналитикой и сроками предоставления отчетности, комфортными для принятия управленческих решений в компании. Это тоже требует данных, которых просто нет в обычной учетной бухгалтерской системе. А вот в ERP такие данные есть!

В общем случае в ERP-системе больше разнообразных «небухгалтерских» данных, нефинансовых в том числе, но очень важных для управления компанией. Можно процитировать Генри Форда: «Когда я изучаю свой баланс, я не могу увидеть там двух вещей: цены моей марки и стоимости моих кадров. Однако именно они и делают меня богачом». В современных бухгалтерских программах есть и цены, и ставки зарплаты, но вот в классической бухгалтерской отчетности этого действительно нет.

1.3.Зачем ERP-система компании

Выше рассматривались отличия ERP-системы от бухгалтерской учетной системы. Из этого следуют основные причины потребности компании в ERP-системе. Система может быть необходима:

● для реального понимания бизнеса и управления им;

● прозрачности данных для аудиторов;

● предоставления требующейся оперативной отчетности по МСФО для родительской компании или инвесторов;

● повышения ценности компании, деловой репутации (гудвил в терминах МСФО), т. к. брендовая система автоматизации, по мнению аудиторов, один из необходимых критериев;

● как конкурентное преимущество: снижение затрат (ФОТ, себестоимость продукции, оборачиваемость склада, ассортиментное планирование) – инструмент для захвата рынка;

● для внедрения бюджетирования – тактического и стратегического;

● введения системы KPI и контроля за ними;

● поддержки «цифровой экономики», как модель предприятия и продукции;

● переход к «Интернету вещей» – новый уровень контроля оборудования и/или конечной продукции.

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

● для внутренних нужд (конкретные бизнес-преимущества для работы компании);

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

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

Еще важный момент сегодняшнего дня – это вхождение в нашу жизнь и работу современных ИТ-технологий: на рабочем месте сотрудника уже может не быть персонального компьютера, вся работа идет через смартфон или планшет, «на ногах» (когда сотрудник в разъездах, а не сидит в офисе). Система должна обеспечивать доступ к корпоративным ресурсам и комфортную работу с таких мобильных устройств. Современные ERP-системы, и 1C: ERP в частности, такое позволяют.

Иногда даже один какой-то пункт и его экономический эффект окупает многолетнее внедрение ERP-системы. А если польз несколько – совсем хорошо!

1.4.Затраты на владение системой (стоимость эксплуатации)

Чтобы закрыть вопрос о понятии «ERP» и перейти наконец-то к основной теме проектов внедрения, нужно рассмотреть еще немаловажные финансовые вопросы затрат на владение системой такого класса.

TCO (англ. Total Cost of Ownership) – это совокупная стоимость владения, общая величина целевых затрат, которые вынужден нести владелец с момента начала владения до момента выхода из состояния владения.

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

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

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

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

Как и из чего формируется стоимость проекта внедрения, будет подробно рассматриваться в главе «Как оценить срок и бюджет проекта». Но там рассмотрение будет со стороны управления проектами, то есть для внедренцев. А для потребителя что?

Прикинем состав затрат на приобретение и запуск системы в работу:

● стоимость «коробочной» версии ERP;

● стоимость лицензий на одно рабочее место;

● стоимость лицензий на сервер;

● стоимость сервера системы управления базами данных (СУБД). Это ПО от сторонних поставщиков. Там своя лицензионная политика: на пользователей, на ядра процессора;

● стоимость аппаратного сервера (нескольких серверов), куда все будет устанавливаться. Возможно, нужен не один, а несколько серверов с объединением в кластер, либо настройки идут через виртуальные машины на очень мощном едином сервере;

● серверные операционные системы для серверов;

● системы резервного копирования;

● услуги по пусконаладке серверов и встраиванию их в сетевую инфраструктуру компании;

● квадратные метры помещения для размещения аппаратуры, вентиляция, аккумуляторные блоки для бесперебойной работы серверов в режиме 24/7;

● затраты на организацию системы удаленного доступа к системе;

● консалтинговые услуги проекта внедрения ERP-системы;

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

● обновление или приобретение новых компьютеров и/или мониторов для рабочих мест сотрудников – будущих пользователей. Это часто не учитывается, а между тем текущий парк персональных компьютеров может не позволить комфортно работать в новой системе (скорость работы, разрешение экрана). А если пользователей много, то и бюджет обновления будет значительным.

Сегодня ERP-системы поставляются в электронном формате, документация также доступна через Интернет, что позволяет поставщику поддерживать документацию и систему всегда в актуальном состоянии, регулярно публиковать обновления для системы.

Но некоторые покупатели, которые ожидают что-то материальное после приобретения ERP-системы, что можно подержать в руках, могут восклицать: «Где все? Мы же заплатили деньги, где система? А нам какую-то ссылку на сайт прислали!»

Рис. 1.4. Коробка с системой и документацией 1С: ERP

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

Рассмотрим отдельно важную статью расходов – на системы резервного копирования.

Очень хочется прокомментировать ситуацию с резервным копированием известной в ИТ-кругах поговоркой: «Есть те, кто еще не делает резервные копии, и есть те, кто уже делает!» Совет: не нужно дожидаться этого «уже»!

Это важный пункт в перечне дел для внедрения, и нужно сразу настраивать создание резервных копий базы данных, т. к. ценность ее перекроет все затраты. Частота бэкапов должна быть разумной, как и глубина хранения версий. Даже откат базы на один день назад – это потеря сотен человеко-часов работы сотрудников и потерянные полдня-день на восстановление. А неделя, а вся база за годы?

Расходы на покупку сервера: как правило, имеющиеся на предприятии серверные ресурсы уже распределены между существующими задачами, и дополнительная нагрузка способна негативно сказаться на новых и старых задачах. Оборудование просто не потянет. А серверы стоят прилично. На этапе проектирования следует предусмотреть модернизацию или приобретение серверного и сетевого оборудования под планируемые объемы данных и нагрузку.

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

Вот мы и переходим к стоимости владения. Что в нее входит?

● Техническое обслуживание серверов (затраты на ИТ-специалиста в штате или приглашаемого на время).

● Подписка на сопровождение и обновления для КИС (для западных ERP-систем это значительная статья расходов, т. к. стоимость подписки может быть 20–30 % от стоимости всех лицензий на КИС в год).

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

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

● Обновление (upgrade) аппаратуры серверов для масштабирования при росте нагрузки или поломках/устаревании/износе.

● Дополнительные регулярные расходы на возникшую из-за появления ERP инфраструктуру в компании.

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

Можно ли как-то оптимизировать затраты на ERP-систему? Можно, если посмотреть в сторону облачных решений и SaaS (Software as a Service) предложений аренды аппаратного и программного обеспечения.

1.4.1.Облачные сервисы как путь снижения затрат

Рассмотрим аспект использования ERP-системы в облаках.

Облака, cloud-сервисы, облачные технологии – модель обеспечения удобного сетевого доступа по требованию к некоторому общему фонду конфигурируемых аппаратных и/или программных ресурсов.

В такой облачной модели нет затрат на ERP-систему:

– Разовых:

● приобретение аппаратных серверов;

● услуги по пусконаладке аппаратуры серверов и серверной комнаты;

● приобретение лицензий на все ПО (сервер приложений, само ERP-решение, лицензии на пользователей, серверные операционные системы);

● резервное копирование;

● обновление (upgrade) серверов по необходимости (поломки, устаревание) или для масштабирования (рост компании и числа пользователей).

– Регулярных:

● оплата ИТ-специалистов по обслуживанию серверов;

● содержание серверной комнаты;

● годовая подписка поддержки на обновление ПО;

● процесс обновления ERP-системы на актуальную версию (тут не все просто, об этом ниже).

В свою очередь, появляются новые регулярные траты – месячная подписка на обслуживание по каждому пользователю или пакетно.

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

Рис. 1.5. Схема облачного сервиса

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

– IaaS (инфраструктура как сервис) – клиент использует физические или виртуальные серверы, дисковые хранилища и прочее оборудование оператора облака для конфигурирования своей ИТ-инфраструктуры.

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

● Оператор несет ответственность за функционирование аппаратных блоков и их связь между собой.

● Обслуживанием ОС и программного обеспечения (включая ERP) занимается клиент.

● Резервное копирование СУБД и приложений настраивает и обеспечивает клиент.

– PaaS (платформа как сервис) – позволяет пользователю установить в облачной инфраструктуре необходимое приложение, использующее операционные системы, языки программирования, библиотеки, СУБД и другие сервисы, предоставленные оператором.

● Оператор обеспечивает функционирование платформы и ее масштабирование при необходимости.

● Клиент занимается только поддержкой и работой приложения.

● Резервное копирование настраивает и обеспечивает оператор.

– SaaS (программное обеспечение как сервис) – клиент использует приложение, запущенное внутри cloud-среды оператора.

● Пользователи подключаются к нему с помощью различных протоколов (HTTP, RDP или VPN) и разных устройств, состав которых определен оператором, возможностями приложения (например, вся работа через веб-браузер).

● Поддержка приложения и аппаратуры полностью осуществляется оператором.

● Клиент может влиять только на ограниченное число настроек (заведение пользователей, назначение прав, включение/выключение дополнительных опций).

● Резервное копирование настраивает и обеспечивает оператор.

Рис. 1.6. Отличие технологий

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

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

● Если предполагается серьезная модификация системы в процессе внедрения, то потребуется модель PaaS.

● Если же ERP-автоматизация будет из нескольких интегрируемых систем от разных поставщиков, под которую потребуется специальная настройка окружения, то, возможно, хорошим вариантом будет IaaS.

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

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

Тут нужно решить для себя:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

● приоритет;

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

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

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

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

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

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

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

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

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

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

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