Текст книги "Введение в управление проектами внедрения 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-системы так внедрять настоятельно не рекомендуется. Почему – станет понятно из последующих глав, из перечня того, что нужно учитывать. Эта категория выделена не просто так, а исходя из суровой реальности: такой подход встречается на практике. Рассматривать детально эту категорию, очевидно, не будем. Такого просто не должно быть.

Для начала нужно сказать, что даже 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 по гибким методикам в ряде случаев вполне возможно – выбор тут за проектной командой.