С 1С я работаю уже примерно 20 лет. Тогда, двадцать лет назад, я поехал на Горбушку, купил диск с 1С «Семеркой», установил ее и внедрил на строительном предприятии, переведя бухгалтерию с бумаги в электронный формат. Это были времена, когда отчетность еще заполнялась от руки и сдавалась на бумаге.
С тех пор я успел поработать в нескольких интеграторах: и как исполнитель, и на стороне заказчика. У меня внушительное портфолио неудачных проектов – именно они произвели на меня самое сильное впечатление, стали для меня важными уроками и причиной создания этой статьи.
До позиции руководителя проекта я дошел классическим путем, без «чит-кодов»: начинал в бухгалтерии, затем был главным бухгалтером, финансистом, финансовым директором, архитектором 1С. Около десяти лет назад увлекся функциональным (и, в какой-то степени, «спортивным») программированием. Сейчас я – руководитель проектов и методолог.
За последние два года, работая в текущем интеграторе, я собрал команду из 10–15 человек. Мы спокойно ведем два–три проекта параллельно, специализируясь в основном на переходах с SAP.
Наш первый опыт – это переход предприятия из сегмента automotive (бывший немецкий производитель, поставщик на автомобильные конвейеры) с SAP на 1С:ERP УХ всего за три с половиной месяца.
Следующий проект – международная французская группа, три завода, тоже в автомобильной отрасли. Сейчас мы ведем уже четыре проекта с поэтапным переводом компаний на единую ERP-систему.
Считаю, что по рентабельности мои проекты выше среднего – во многом благодаря тому, что я вкладываю много времени в развитие аналитиков: стараюсь, чтобы они могли выполнять больше задач за меньшее время.
У нас амбициозные планы – хотим увеличить число проектов и вдвое расширить команду аналитиков, при этом сохранив четкую, слаженную структуру – не стадо мустангов, а оркестр, где каждый знает свою партию.
Основные проблемы при переходе с SAP на 1С:ERP
| Проблема | Решение |
|---|---|
| Отсутствие опыта работы с 1С у пользователей. | Проводить крайне кропотливое моделирование и обучение, оставлять подробные инструкции даже по «простым» функциям. |
| Большое число аналитиков на проекте, каждый из которых имеет персональный опыт и методику работы. | Стандартизировать методику на проекте. |
| Глубоко адаптированная SAP под специфику предприятия не может быть заменена «коробочной» 1С:ERP. | Количество доработок достигает 300–400 единиц. |
| Отсутствие описанной системы на уровне бизнес-процессов. | Проводить 100% аудит системы с выявлением бизнес-процессов и отрисовкой графических схем. |
| Успеть к дедлайну отключения SAP. | Радикально повысить производительность труда аналитиков, в том числе за счет отказа от использования MS Office. |
| SAP-проекты – очень сложные и проблемные. | Придумать стандартную технологию и действовать по шаблону. |
В целом это касается любого проекта ERP, даже не 1С, ведь это стандартные проблемы.
Первая и самая большая проблема – отсутствие как такового опыта у будущих пользователей 1С. Мы не имеем права рассчитывать на то, что они уже что-то умеют. Поэтому нам нужно очень тщательно моделировать систему, максимально покрывать ее инструкциями и уделять много времени обучению.
Также на таких проектах обычно работает большое количество аналитиков, в том числе новых, которые только пришли с рынка. И поскольку у каждого аналитика свой собственный персональный стиль, нужно их стандартизировать, чтобы они выполняли работу в одном ритме с другими аналитиками. Тогда проект идет плавно, но уверенно.
Как правило, SAP-системы – это отраслевые решения, которые десятки лет разрабатывались в гигантских международных холдингах. У нас есть опыт таких проектов, и мы знаем, что эти системы очень сложно заменить «коробочным» решением 1С. Поэтому даже в быстрых и эффективных проектах мы говорим о большом числе доработок – это сотни позиций, которые нужно реализовать в очень короткие сроки. Это, в свою очередь, создает дополнительные требования к скорости оформления технических заданий, их выполнения и контроля.
Как правило, у таких компаний отсутствует описание бизнес-процессов. А от того, как быстро мы определим, какие процессы необходимо внедрить в новой системе, зависит все: сможем ли мы успеть, насколько точно воспроизведем текущую модель, и вообще – потянет ли команда.
Специфика ERP-систем в том, что в них входит все подряд: все блоки, все подсистемы – кадровый учет, CRM, воронка продаж, документооборот. Такова судьба ERP-систем. Поэтому чем раньше мы поймем истинный объем исторической системы, тем точнее сможем воспроизвести его в новой.
Как правило, существует конкретная дата отключения SAP, и у нас нет возможности сказать: «Давайте перенесем на следующий год». Если система не будет запущена, предприятие просто остановится.
Все это делает SAP-проекты очень сложными с точки зрения организации и может серьезно «ушатать» команду – архитекторов, лидеров и руководителей проектов.
Создание шаблона ERP-tools для стандартизации проектной работы
Было принято принципиальное решение – придумать шаблон, который позволит максимально рутинизировать работу аналитиков и всей проектной команды на подобных проектах, чтобы каждый раз не начинать с чистого листа и не учиться заново кататься на велосипеде.
Так был создан шаблон ERP-tools – база данных на платформе 1С. Он выполняет три основные функции:
-
Описание и внедрение сложных программных продуктов, таких как SAP или 1С, где есть сложная бизнес-логика и много видов пользователей. Все это может быть описано в этой нотации.
-
Развитие программного продукта, управление изменениями и доработками.
-
Разработка любого ПО с нуля.
Система построена на базе библиотеки стандартных подсистем 1С. Чтобы она стала единым местом работы для аналитиков, архитекторов и программистов, в нее были интегрированы различные подсистемы. Главное – это функциональное бизнес-моделирование, которое позволяет описать сложную комплексную ERP-систему с точки зрения бизнес-процессов, выделить отдельные артефакты системы и контролировать их.
Функциональные подсистемы ERP-tools
Также есть подсистема «Управление командой». Мы используем ее для управления разработкой, потому что 200–400 доработок нужно сделать буквально за два месяца. Нужны механизмы, которые позволяют команде быстро генерировать технические задания, выполнять их и фиксировать конечный результат.
После этого появился полноценный Service Desk, который мы используем для поддержки опытной и промышленной эксплуатации. Все обращения поступают непосредственно в базу данных, рядом с артефактами. Аналитикам проще собирать информацию, формировать статистику и выдавать заказчикам инструкции по функциям системы.
Есть «Управление проектом». Там строятся все графики, отражаются оплаченные часы, time&material, реализована интеграция с Redmine. Это позволяет организовывать проект внутри интегратора.
Есть уникальная подсистема «Загрузка начальных данных». Ее смысл в том, что мы отказались во всех проектах от услуг программистов при загрузке начальных данных, так как это дорого, долго и не всегда качественно. Вместо этого мы готовим специальные шаблоны и в нужный момент загружаем их через программного робота фирмы 1С – 1С:Тестировщик. Это ускоряет процесс и делает проект более рентабельным.
Подобные системы есть в любом интеграторе и крупном бизнесе, который масштабирует проектную работу, но преимущество этой системы в том, что ее можно купить. Обычно такие решения не продаются даже клиентам, и после внедрения у заказчика остается только файл-архив, больше похожий на файл-помойку.
Workflow и принцип «все в одном»
Каким образом наша команда не запутывается в сложных проектах? Это принципиальная схема – workflow, заложенный в системе. Система – не чистый лист, в ней есть проектная технология, которая позволяет аналитикам четко следовать процессу. Мы практически не проводим ежедневные стендап-митинги, я не уточняю, чем занимается аналитик, не спрашиваю, почему что-то не сделано. Все работают по встроенному бизнес-процессу. Я лишь периодически контролирую успешность этого процесса по объективным показателям.
Здесь реализована схема «все в одном». В какой-то момент нам понадобились графические схемы для визуализации – на следующий день они появились в программе. Это стандартный графический редактор, встроенный в 1С. Он похож на EPC и позволяет быстро отрисовывать любые сложные взаимосвязи. При работе с неподготовленным пользователем такая схема особенно удобна.
Мы не используем внешние редакторы, не загружаем файлы на сайты и не пытаемся сформировать красивые таблички. Все находится внутри системы. Если это графическая схема – она рядом с артефактом. Это ускоряет работу аналитиков и позволяет формировать печатные формы документации, включая схемы, буквально в один клик.
Мы полностью отказались от пакета Microsoft Office. Не используем Word, Excel, Google Таблицы, Confluence, MS Project. Эти инструменты плохо работают на больших проектных командах. Почтой тоже не пользуемся. Все, что можно, перенесли в эту систему, и она является нашим провайдером.
Теперь посмотрим на примере бизнес-процессов основные артефакты.
Анализ бизнес-процессов и их структурирование
С чего начинается работа аналитиков на проекте? Мы заходим и первым делом анализируем все бизнес-процессы. На любом промышленном предприятии, даже небольшом, их порядка 100–150. Если пытаться выяснить их вручную, можно потерять 2–3 месяца.
У нас уже есть опыт внедрения подобных проектов на разных предприятиях. Мы приходим к заказчику не с чистым листом, а с чек-листом бизнес-процессов. Опрашиваем: есть ли у вас такие процессы или нет. Таким образом быстро получаем общее информационное описание.
ERP-система – это сложная структура, в ней есть активности, которых можно даже не ожидать: кадровый учет, CRM, документооборот и многое другое. В бизнес-процессе важно, чтобы аналитик зафиксировал шаги процесса – функции системы. В среднем в каждом процессе от одного до десяти шагов.
Далее необходимо указать организационную структуру. Если в проекте множество юрлиц, каждое из них может иметь свой набор бизнес-процессов. Например, торговый дом и производство: у них будут общие и раздельные процессы. Такое деление позволяет формировать проектную документацию не по всей компании, а по конкретному юрлицу – с указанием, какие бизнес-процессы и функции системы там присутствуют.
Мы углубляем эту практику: выдаем функционально-процессные модели по отдельным организациям – например, по продажам для организации X или по закупкам для организации Y. Получатель информации (коммерческий директор, директор по закупкам) читает именно ту документацию, которая относится к его подразделению. Это существенно повышает ценность документа по сравнению с тысячестраничным отчетом, где нужно искать нужные разделы.
Нам это ничего не стоит – все активности ведутся в системе, просто формы документов можно распечатать в разных вариантах.
Есть раздел «Дополнительные поля» – руководитель проекта может добавить их к артефактам системы. Если проект ГОСТовый и требуется раскрывать специфическую информацию в отдельных документах, эти поля можно задать централизованно, и аналитики будут их заполнять. В итоге формируется печатная форма, где документация раскрыта в Word-подобном стиле.
Принципиально мы не используем Word-редактирование. Это высвободило значительные трудозатраты, которые мы направляем на детальную проработку системы.
Работа с объектами метаданных и функциями системы
После того как зафиксированы бизнес-процессы, аналитик приступает к выполнению шагов этих процессов. Он должен определить, с помощью каких объектов системы (объектов метаданных) выполняется каждый шаг. Мы регистрируем все объекты метаданных, с которыми взаимодействует пользователь: создает, редактирует и так далее.
В среднем это около 100 справочников на простом проекте ERP и до 200 видов учетных документов. Общее количество объектов спокойно превышает 300 единиц. В дальнейшем объекты метаданных становятся каркасом информационной системы, который накапливает данные и обеспечивает быструю навигацию. Мы можем быстро найти, какие требования относятся к заказу клиента, какие из них имеют признак функционального разрыва, какие функции к этому объекту зарегистрированы, какие обращения и инциденты были связаны с ним. Это несравнимо с методом Control+F и попытками понять, куда привел поиск.
После этого мы регистрируем функции. Функция – это шаг бизнес-процесса, единичное действие с объектом метаданных. Например, создание заказа клиента или постановка заказа в отгрузку. В среднем количество функций превышает 600 единиц – примерно две функции на один объект метаданных.
Эти цифры показывают, что речь идет не о небольшой ERP-программе, а о системе, в которую включено все, что только можно. Поэтому особенно важно правильно организовать визуализацию этой картины. Word и Excel с этим не справляются, так как это слишком плоские инструменты, в отличие от базы данных, которая способна связать все взаимосвязи и реализовать их.
Статусы функций и подход к согласованию с заказчиком
Функции имеют статусы. Это важный элемент качественного анализа. У нас несколько статусов: «Выявлен», «Подготовлен», «Сдан заказчику», «Допущен в промышленную эксплуатацию» и «Эксплуатируется». Все 600 функций должны быть сданы заказчику, чтобы по каждой заказчик подтвердил, что его устраивает поведение системы при выполнении конкретного действия, например, при создании заказа клиента. Если его не устраивает – требуется доработка.
600 функций сдать заказчику невозможно, потому что в ходе проекта обычно анализируются только основные бизнес-процессы и функции – не более 150. Остальные 400–500 функций – внутренняя работа команды во главе с функциональными архитекторами. Они должны проработать все эти функции, убедиться, что нет противоречий, и подготовить готовые рекомендации на случай, если функция будет востребована в первые дни промышленной эксплуатации – например, при создании номенклатуры.
Создание инструкций: подход «делайте как для мамы»
Мой любимый артефакт – инструкция. Самый нелюбимый, наверное, всеми вами, потому что создать 600 инструкций по 600 функциям кажется невозможным. Но мы делаем это на каждом проекте, потому что отказались от инструмента, который для этого не предназначен. Word не предназначен для подготовки инструкций.
Для этого мы используем обычный документ 1С. У него есть табличная часть с заголовком, комментариями, описаниями и картинками. Создание инструкции в таком виде становится простым. Не нужно искать файл, брать его на редактирование, искать место для вставки. Если появляется новый пункт в требовании, в инструкции просто находите между пятым и шестым шагом место, добавляете новый шаг, вставляете картинку, сохраняете – и работа продолжается. Раз в неделю кто-то, может быть, обновляет инструкции, они уходят пользователям. Мы на это время не тратим.
Почему я считаю работу с инструкцией самой важной на проекте?
Посмотрим инструкцию по функции, которую знают все – создание контрагента. Все, кроме тех, кто никогда не работал в 1С (помним, что речь идет о SAP). Первые две строки инструкции объясняют, как найти нужный справочник в ограниченном интерфейсе пользователя.
Я прошу аналитиков использовать одно правило при подготовке инструкции: делайте как для мамы. Представьте, что мама – немолодой человек, работает в SAP, и внезапно происходит переход в 1С. Ей не должно быть больно от этого перехода. Она должна понять, как выполнить действие по вашей инструкции.
Выявление и согласование требований через инструкции
После этого нажимаем кнопку «Создать». Система 1С спрашивает: «Введите ИНН». Мы вводим ИНН, происходит автозаполнение КПП и юридического адреса.
Можем ли пройти дальше? Не можем, потому что сталкиваемся с альтернативным поведением системы. Она может выполнять это действие, а может нет. Аналитик не имеет права решать за пользователя, как система должна себя вести. Поэтому регистрируется требование.
Вот пример такого требования. Это сложный артефакт с большим количеством полей. Рассмотрим только статусы этого требования:
-
Не согласовано заказчиком
-
Отклонено заказчиком
-
Отклонено командой
-
Согласовано заказчиком
-
Согласовано функциональным архитектором
-
Согласовано РП
-
Выполнено включением в инструкцию
Допустим, требование зарегистрировано. Идем дальше по карточке создания контрагента. Система спрашивает, какая будет группа доступа у партнера. Группа доступа не задается на уровне начальных задач проекта – это мелкий реквизит, находящийся вне контекста.
Задача аналитика в этот момент – выявить все возможные альтернативы, которые дает 1С. Нужно уточнить, будет ли использоваться сервис 1С:Контрагенты и будет ли вообще применяться группа доступа. После этого аналитик идет к заказчику, получает подтверждение.
Если заказчику все подходит, аналитик обязан провести согласование с функциональным архитектором. Когда аналитики проходят 600 инструкций, в итоге получается около тысячи требований – это все альтернативы, заложенные в коробочной версии. Плюс в среднем около 400 доработок, которые заказчик попросит в явном виде.
После того, как аналитик отправит на согласование функциональному архитектору, достигается еще одна важная цель – функциональный архитектор наконец-то включается в контекст проекта. Обычно он ждет два месяца, пока появится проектное решение на тысячу страниц, читает его и понимает, что уже поздно что-то менять. Здесь все иначе: архитектор получает уведомления в системе и в Telegram, видит новые проектные решения, что он должен с ними ознакомиться, должен их согласовать или отклонить.
Затем требование согласовывает руководитель проекта. Это важный этап, потому что руководитель знает договорные условия. Например, если завод оборонный и у него нет выхода в интернет, сервис 1С:Контрагенты нужно закрывать. Или если аналитики и архитекторы придумали сложный АРМ, но нет бюджета на разработку – решение нужно отложить или закрыть.
После согласования аналитик получает уведомление в Telegram и 1С, что требование согласовано. Он обязан доработать инструкцию: добавить пункт о ручном вводе юридического адреса, если сервис 1С:Контрагенты отключен. В инструкции он указывает ссылку на требование, вызвавшее изменение поведения системы – что мы делаем это вручную, потому что у нас отказ по использованию сервиса 1С:Контрагенты.
После этого система автоматически повышает статус требования до «Выполнено включением в инструкцию». Контроль не требуется: за время проекта 5–10 аналитиков должны обработать около тысячи требований и включить их в инструкции с иллюстрациями, чтобы руководитель проекта, архитекторы и команда могли видеть, как именно требование реализовано.
Работа с техническими заданиями и испытаниями
Если в требовании есть функциональный разрыв, нужно заполнить две дополнительные табличные части, техническое задание, где тоже в режиме «картинка – описание, картинка – описание» мы готовим ТЗ.
300–400 ТЗ можно сделать даже в коротком проекте. В минимальном режиме одно ТЗ создается за минуту: добавить интерфейсы, описание решения, подготовить печатную форму и отправить заказчику в Excel или Word.
Проблема технических заданий в том, что если отправить ТЗ по почте трем заказчикам и каждый пришлет свои комментарии, оригинала больше нет – остаются три разных версии, а исходник в лучшем случае лежит в почте. Здесь эта проблема решена: ТЗ хранится непосредственно в системе в оригинале, и руководители разработки могут сразу к нему приступить.
Таким образом мы полностью соблюдаем все формальности даже на коротких проектах – полностью документировать технические задания и обязательно закрывать их.
Масштаб проекта и сравнение подходов
В конце немного математики:
-
150 бизнес-процессов с четырьмя статусами,
-
600 функций с четырьмя статусами,
-
300 объектов метаданных,
-
600 инструкций,
-
1000 требований с пятью статусами,
-
400 технических заданий с двумя статусами,
-
400 протоколов испытаний с двумя статусами.
Больше 10 000 артефактов и их состояний – это стандартный ERP-проект.
Если систему разложить на фрагменты, как черный квадрат Малевича на части, и аккуратно, шаг за шагом, работать со статусами артефактов, то в итоге собирается цельная картина. Причем собирается она не дольше, чем обычно – время готовности системы к эксплуатации 3,5–4 месяца. Мы описываем полную бизнес-процессную модель, выявляем 1000 требований, делаем 400 доработок, выпускаем и уходим с проекта.
Второй вариант – традиционный. Собирается только периметр пазла, потому что это просто. Как правило, периметром выступает перечень функциональных разрывов, сформированный к началу проекта. Это 50–60 позиций. Команда занимается ими полгода, а при выходе в промышленную эксплуатацию оказывается, что функциональность не проработана, потому что нет инструментария для визуализации сложных систем.
По второму варианту я работал и уверен, что все работали. Это некомфортные условия: работа нервная, к концу проекта команда обычно разбегается на новые проекты, которые еще в начальной стадии, где можно снова шесть месяцев сидеть.
Работа по первому варианту более напряженная с первого дня, но дает гарантированный стабильный результат, которым можно гордиться.
Проработка ФМ возможна только за счет специализированного ПО и полного отказа от неэффективных процессов, связанных с редактированием WORD/Excel.
Используйте готовые велосипеды и не изобретайте новых, катайтесь на здоровье, получайте удовольствие от работы аналитиком 1С или руководителем проекта.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
