Kitobni o'qish: «Введение в управление проектами внедрения ERP-систем»

Электронный аналог печатного издания "Введение в управление проектами внедрения ERP-снстем. 2-е стереотипное издание" (ISBN 978-5-9677-3406-9, М.: ООО «1С- Паблишннг». 2024; артикул печатной книги по прайс-листу фирмы «1С»: 4601546148223; по вопросам приобретения печатных изданий издательства «1С-Паблншинг» обращайтесь к партнеру «1С», обслуживающему вашу организацию, или к другим партнерам фирмы «1С»)

© ООО «1С-Паблишинг», 2025

© Оформление. ООО «1С-Паблишинг», 2025

Все права защищены.

Материалы предназначены для личного индивидуального использования приобретателем.

Запрещено тиражирование, распространение материалов, предоставление доступа по сети к материалам без письменного разрешения правообладателей.

Разрешено копирование фрагментов программного кода для использования в разрабатываемых прикладных решениях.

⁂

Введение

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

В основе всего зачастую лежит свод знаний от PMI – PMBOK. Особенностью данного издания является упор на практическую сторону вопроса управления проектом внедрения ERP-системы. По опыту общения на семинарах, проводимых фирмой «1С», автором неоднократно замечалась потребность в таком кратком пособии для начинающих ERP – специалистов, с которого можно начать путь в мир проектного управления.

Понятно, что в хорошей компании, занимающейся внедрениями, есть проектный менеджер (project manager), который все прекрасно знает и применяет на практике, натаскивает команду со стороны исполнителя проекта и рабочую группу со стороны заказчика, управляет и минимизирует риски. С чего-то нужно начать, чтобы стать хорошим специалистом и участником такой «правильной», применяющей проектные методики, команды? Данная книга должна в этом помочь! Она будет интересна студентам и начинающим специалистам, которым в будущем предстоит столкнуться с реальной практикой работы на проекте (со стороны пользователей или специалистов по внедрению КИС).

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

Отзывы и предложения по улучшению этой книги и серии книг «Академия ERP» можно присылать на электронную почту publishing@1c.ru.

Принятые термины и сокращения

● 1C: ERP – система управления предприятием «1С: ERP Управление предприятием» на базе платформы «1С: Предприятие 8».

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

● ERP – планирование ресурсов предприятия (англ. Enterprise Resource Planning).

● FIT-GAP анализ – анализ «подходит – не подходит» (от англ. слов «подходит» и «разрыв»).

● IoT – Интернет вещей (англ. Internet of Things).

● ISO – международная организация по стандартизации (англ. International Organization for Standardization).

● ITIL – библиотека инфраструктуры информационных технологий (англ. IT Infrastructure Library).

● KPI – ключевые показатели эффективности (англ. Key Performance Indicators).

● MRP – планирование потребности в материалах (англ. Material Requirements Planning).

● PERT – техника оценки и анализа программ и проектов (англ. Program Evaluation Review Technique).

● PM – он же «ПиЭм» или «РП», руководитель проекта (англ. Project Manager).

● PMBOK – свод знаний по управлению проектами (англ. Project Management Body of Knowledge).

● PMI – институт по управлению проектами (англ. Project Management Institute).

● PMO – офис управления проектами (англ. Project Management Office).

● RDP – протокол удаленного рабочего стола (англ. Remote Desktop Protocol).

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

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

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

● RLS – разграничение доступа на уровне записей (англ. Record Level Security).

● ROI – окупаемость инвестиций (англ. Return On Investment).

● SaaS – программное обеспечение как услуга (англ. Software as a Service).

● SLA – соглашение об уровне предоставления услуги (англ. Service Level Agreement).

● T&M – оплата по факту (англ. Time & Material).

● TCO – совокупная стоимость владения (англ. Total Cost of Ownership).

● VPN – виртуальная частная сеть (англ. Virtual Private Network).

● ИСР или WBS – иерархическая структура работ (англ. Work Breakdown Structure).

● ИТ/IT – информационные технологии (англ. Information Technology).

● КИС – корпоративная информационная система.

● МСФО – международные стандарты финансовой отчетности.

● ПО – программное обеспечение.

● РСБУ – российские стандарты бухгалтерского учета.

● СМИ – средства массовой информации.

● ФОТ – фонд оплаты труда.

Глава 1. Что такое 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. Как выбрать 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-система нужна (а такое бывает, т. к. определяется, например, стоимостью самой системы или поддержкой отраслевой специфики), то выбор самой системы уже ясен, и проводится выбор исполнителя для проекта автоматизации.

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

Как управлять рисками и бюджетом проекта, в этой книге описано для стороны исполнителя. Можно эти знания применить и для отдела внутри компании.

Если сама система еще не выбрана или есть различные отраслевые решения внутри одной ERP-системы, то среди них нужно выбрать подходящее решение. Для этого понадобится список функциональных требований оформить в виде RFP, по которому будет проводиться fit-gap анализ.

О fit-gap анализе речь пойдет в следующем разделе этой главы.

На данном этапе считаем, что такой анализ проведен, результаты получены. Что дальше?

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

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

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

До момента выбора системы такую информацию «из первых рук» можно получать на профильных мероприятиях, где доклады о ходе внедрения и интересных практических кейсах делают сами пользователи ERP-системы. Например, у «1С» такое мероприятие проходит ежегодно: «Бизнес-форум 1С: ERP» http://1c.ru/bf/. После докладов можно подойти к докладчикам и узнать подробности, договориться о визите в гости с показом системы.

2.2.2.Со стороны исполнителя

В какой-то момент приходит запрос об автоматизации от потенциального клиента. Запрос может прийти:

● на корпоративный e-mail, указанный на сайте;

● через форму обратной связи сайта;

● через знакомых;

● на личных встречах на профильных форумах и других мероприятиях (да хоть в бане у общих знакомых) вместе с вручением визитки с контактами.

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

Но чаще запрос будет неформальным письмом: «Нам нужна автоматизация, что вы можете предложить и что ваша система может?»

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

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

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

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

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

Если шаблона коммерческого предложения нет – нужно его сделать! Для этого можно воспользоваться готовыми шаблонами из различных проектных методологий. О них речь пойдет в следующих главах.

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

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

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

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

● менеджер, который ведет переговоры;

● руководитель проектов;

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

● ведущий консультант по системе (он будет показывать ERP-систему и делать по ней доклад);

● (опционально) ведущий разработчик (для оценок на лету возможности реализации того или иного требования в процессе разговора);

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

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

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

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

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

Если совсем кратко, на что обратить внимание при проведении презентации:

● вежливость и внешний вид, впечатление профессионализма;

● интерес к проблематике заказчика, а не решению;

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

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

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

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

● предоставить протокол встречи всем участникам в течение нескольких дней после презентации.

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

Об этапах проекта и его жизненном цикле речь пойдет в главе «Этапы и документация проекта».

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

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

2.3.Fit-gap анализ разных систем

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

Если исполнителями являются не внешние специалисты, а команда сотрудников в штате компании, то подход тот же самый. Здесь и далее «исполнитель» – это специалисты, отвечающие за автоматизацию и хорошо знающие рассматриваемую ERP-систему, а «заказчик» – заинтересованная в проекте сторона, путь даже внутри одной и той же компании.

При fit-gap анализе за основу берется список требований от заказчика, он передается в составе RFP, разбит по разделам (модулям) системы: продажи, закупки, бухгалтерский и налоговый учет, производство, казначейство и прочие. Этот список переводится в таблицу, если изначально был не в виде таблицы, и к нему добавляются столбцы для оценок анализа.

Типовой шаблон таблицы для проведения fit-gap анализа содержит столбцы:

● Наименование требования – краткое описание критерия для оценки;

● Приоритет – важность и очередность для автоматизации: 1 – высший приоритет, 10 – низший;

● Обязательность – критичность реализации на первом этапе для запуска в эксплуатацию (так называемое must have – должно быть сразу);

● Поддержка – поддерживается штатно «из коробки»;

● Настройка – поддерживается настройкой системы (не требует программирования);

● Модификация – поддерживается доработкой (требует программирования);

● 3-я сторона – поддержка решениями третьих сторон;

● Будет в следующих версиях – поддержка анонсирована в следующих версиях решения;

● Не поддерживается – нельзя сделать, технические и функциональные ограничения;

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

● Комментарий к оценке fit-gap – пояснения выбранной отметки при анализе.

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

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

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

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

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

Потому выше рассмотрена более общая структура таблицы fit-gap анализа, где такие тонкости вынесены в отдельные столбцы.

Еще вариант этой таблицы: один столбец «fit-gap», в который ставится числовая оценка сближения или разрыва. Например, по шкале от 10 до 0, где 10 – подходит идеально, 1 – не подходит, 0 – нельзя доработать. Тогда промежуточные оценки показывают степень и сложность доработок.

Рис. 2.1. Пример таблицы fit-gap анализа требований

Как, собственно, заполнить этот файл на стороне исполнителя?

Привлекаются все эксперты (коллеги по компании-исполнителю) по системе:

● рассылкой по электронной почте для оценок каждым своего блока и первоначального знакомства с требованиями;

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

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

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

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

Заказчик, собирая такие fit-gap таблицы по своим требованиям, может их соотнести между собой, это позволит определить применимость той или иной ERP-системы, если идет выбор между разными системами. Поэтому столбцы для fit-gap анализа желательно добавить сразу на стороне заказчика, чтобы все участники тендера работали с одним шаблоном RFP и потом можно было соотносить результаты.

Если таблица объемная и зрительно сравнить затруднительно, вводится дополнительный столбец с оценками по каждой отметке, где проставляются баллы: поддержка «из коробки» – максимум, «не поддерживается» – ноль. Далее по сумме баллов определяется победитель.

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

Зато если система не подходит совсем, то это сразу будет видно по сплошным «разрывам» в анализе.

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

2.4.ИТ-ландшафт текущий и перспективный

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

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

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

В части ИТ-ландшафта нужно составить схему текущего (as is) состояния и взаимосвязи систем и иных программ, используемых в бизнес-процессах компании.

Эта схема потребуется для лучшего понимания задач предстоящей автоматизации и выработки и выбора вариантов перспективных состояний, возможно, с какими-то промежуточными этапами на моменты перехода из текущего состояния в целевое (to be).

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

Типичный пример такой связи – это обмен системы «клиент-банк» с учетной системой через файл специального текстового формата, содержащий информацию о платежных поручениях. Файл при этом выгружает и загружает оператор. Либо настроен прямой обмен и промежуточные файлы не используются, либо никакого обмена нет и все платежки перебиваются вручную в обе системы. На схеме это можно рисовать разным типом стрелок или подписывать, как именно связаны системы.

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

Итак, с чего начать составление карты ИТ-ландшафта «как есть»?

● С составления списка используемых систем и программных средств.

● Часто для каких-то задач может использоваться база в виде Excel-файла, такие базы тоже нужно учитывать.

● На схеме каждый объект, содержащий данные, рисуется отдельным элементом.

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

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

Рассмотрим пример такой схемы «как есть». В холдинге, состоящем из нескольких юридических лиц, есть множество бухгалтерских систем. По каждому юрлицу – своя система, так сложилось исторически, велись разными бухгалтерами разрозненно. Для ведения зарплаты и кадров используется единая система. Используются разные банки со своими системами «клиент-банк». Управленческий учет на предприятии первичный, ведется в отдельной системе и базах в Excel-файлах, где по результатам деятельности собирается управленческая отчетность по холдингу. Присутствует связь с бухгалтерскими системами по первичным документам, а также с внешней системой заказов у основного поставщика с интеграцией через web-сервис.

Рис. 2.2. Пример схемы. ИТ-ландшафт систем «как есть»

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

Как рисовать перспективную схему «как будет»?

● Выявить элементы, которые будут заменяться, объединяться или как-то меняться в процессе проекта автоматизации.

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

● Нарисовать связи, которые остаются, но уже применительно к ERP-системе.

В нашем примере получается такая целевая схема «как будет».

Рис. 2.3. Пример схемы. ИТ-ландшафт систем «как будет»

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

Рис. 2.4. Пример общей схемы аппаратных компонентов сети компании

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

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

Рис. 2.5. Пример схемы. ИТ-ландшафт систем после первой очереди автоматизации

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

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

2.5.Нагрузочные тесты и выбор «железа»

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

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

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

Дополнительно нужно оценить ожидаемый объем данных и динамику его прироста в месяц/год:

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

● количество контрагентов и их прибавление в месяц, в год;

● количество заключаемых договоров, заказов в месяц, в год;

● количество документов по основной деятельности (закупки, продажи, производство) в день, месяц, год;

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

● количество касс, ККМ, р/с, клиент-банков, эквайринговых терминалов;

● количество внеоборотных активов и динамика изменений;

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

● число сотрудников, динамика изменений и многое другое.

На непосредственную нагрузку на серверы (количество процессорных ядер и ОЗУ) влияет:

● количество одновременно работающих пользователей;

● что именно они делают, типовой сценарий работы;

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

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

Детальные рекомендации по подбору оборудования даны на сайте «1С» в разделе для технических специалистов: https://its.1c.ru/db/metod8dev#content:5810:hdoc

У фирмы «1С» для целей нагрузочного тестирования есть специальный инструментарий – Тест-центр. Тест-центр – инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе «1С: Предприятие 8». С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях.

Подробнее о нем можно почитать на сайте: http://v8.1c.ru/expert/tc/tc_overview.htm

Рис. 2.6. Общая схема работы Тест-центра

В общем случае сценарий нагрузочного теста ERP-системы для выбора «железа» такой:

● Подготовить нагрузочный тест для Тест-центра.

● Запустить нагрузочный тест на одном сервере.

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

● Реализовать инфраструктуру так, чтобы она была горизонтально масштабируема (мало ресурсов – докупили сервер, ресурсы увеличились).

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

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

2.6.Окупаемость и обоснование затрат на автоматизацию

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

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

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

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

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

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

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

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

Защитив и обосновав бюджет на проект внедрения перед учредителями и иными заинтересованными сторонами, мы переходим к вопросам непосредственно проекта внедрения и управления им.

Глава 3. Как внедрять ERP-систему

3.1. Технологии управления проектами

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

Другое дело, какую методологию выбрать, как все распланировать, оценить, соблюдать и контролировать выполнение работ, минимизировать различные риски и проблемы?

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

Технологии и стандарты управления проектами можно разделить на три условные категории:

– Гибкие (Agile), такие как Scrum, Kanban, Extreme programming. Представляют собой:

● Семейство «гибких» подходов к разработке программного обеспечения. Такие подходы иногда называют фреймворками или agile-методологиями.

● Манифест: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

● Бюджет всего проекта заранее неизвестен, есть примерные оценки, работа по факту (time in material).

– Классические, такие как ISO 21500, ГОСТ 34, PMBOK. Представляют собой:

● Каскадные, или «водопадные», модели (waterfall model) – поток из последовательности этапов/фаз работ над проектом.

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

● Бюджет заранее известен и часто фиксирован (fix price).

– Когда нет методологии:

● Основная идея: «Зачем какие-то методологии и управление, просто сделайте/сделаем, что просим/просите».

● Может трактоваться как подвид гибких технологий, но это не так.

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

● На практике встречается в небольших командах из 1–2 специалистов и в краткосрочных работах.

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

● Управления рисками нет (а сами риски есть), сроки и объем работ проконтролировать сложно. Типичная итерация: «Готово?» – «Да, почти» – «Когда будет?» – «На следующей неделе», – и так каждую неделю. Понять, где мы сегодня, практически нельзя – точнее, можно, но для этого нужно на этот «непроект» применить какую-то методологию и формально описать, что было нужно сделать, что уже сделано, что осталось, какие трудозатраты и ресурсы.

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

3.1.1.Agile-методологии

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

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

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

Мнение практиков в поддержку гибких походов для ERP-проектов из круглого стола семинара по 1С: ERP в апреле 2019 г.: «ERP-система замечательно внедряется частями. Главное – грамотно спланировать этапы внедрения. А функционал системы настолько велик, что спроектировать все от и до качественно заранее очень сложно, поэтому можно использовать гибкие подходы с короткими итерациями выпуска рабочей версии».

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

Обычная практика и мнение против гибких методик для ERP: «Внедрение ERP-системы часто проходит по классическим проектным методологиям в силу объемности и сложности внедряемой функциональности, когда нужно все четко спроектировать, спланировать и оценить».

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

Рис. 3.1. Фото с примером доски задач по agile-методологии

Гибкие методологии возникли в ИТ-сфере в начале 2000-х годов, потом стали применяться в других сферах деятельности.

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

Будет заблуждением считать, что «гибкость» – это «когда нет методологии». Нет! Во всех методиках есть свои правила, которые нужно соблюдать, какими бы странными они ни казались поначалу.

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

В данной книге не будет подробного рассмотрения гибких методологий и отличий Scrum от Kanban или как организуется парное программирование в Extreme programming. Это все очень интересно и можно изучить самостоятельно.

Если есть желание применять гибкие методики, лучше опираться на более классические проектные технологии, чтобы было полное понимание, от чего отказываться в пользу «гибкости» и к чему это может привести. А не по принципу: «У нас все гибко, и всякие там непонятные вещи из управления проектами нам совсем не нужны».

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

Из опыта практиков гибких методик для внедрения ERP: «Спринты и итеративность при моделировании тоже крайне эффективны, а не только на этапе разработки. Также сам этап запуска системы спринтами, разбитыми по разной функциональности и пользователям, позволяет сильно сократить градус экстрима на опытной эксплуатации».

Так что внедрение ERP по гибким методикам в ряде случаев вполне возможно – выбор тут за проектной командой.