Практика описания архитектуры системы на начальных этапах проекта внедрения 1С:ERP.УХ с помощью 1С:СППР 2

Меня зовут Евгений Филиппов, я работаю экспертом в компании IBS.

То, что я делаю в течение последних 30 лет, рано или поздно сводится к задачам техподдержки. Длительное время занимаюсь технической поддержкой именно корпоративных крупных внедрений: в свое время это было в основном решение вопросов производительности, теперь в немалой степени – описание систем.

В докладе я хочу рассказать о применении СППР 2 для описания архитектуры системы.

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

• Мы рассмотрим особенности СППР, которые следует учитывать, чтобы все нормально работало.

• И я расскажу про то, как дорабатывать СППР – что при этом важно помнить.

Функциональный и организационный объем проекта

Кратко расскажу об истории проекта – с чего все началось, и к чему в итоге привело.

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

• СППР для этой задачи подходила, но не идеально – хотя, пожалуй, это лучшее, что было и есть для решения таких проблем.

• Ключевой плюс СППР – ее можно доработать, потому что она написана на 1С. Но это не единственный ее ключевой плюс, и об этом я тоже расскажу.

Продукт СППР лучше других систем подходил для решения поставленной задачи по следующим причинам:

• Обеспечивалось описание системы в привязке именно к механизмам 1С. Никакой другой сторонний продукт, какой бы он распиаренный и многофункциональный не был, не связан с метаданными 1С. А СППР с метаданными 1С связан, и это то ключевое преимущество, которое дает возможность принять решение о том, что использовать для описания системы.

• СППР написан на 1С и может быть доработан непосредственно командой проекта. А доработка там нужна – без этого не обойдется.

На слайде – характеристики проекта.

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

• Большое количество внедряемых предприятий, каждое из которых – со своими особенностями.

• Общее количество пользователей – свыше 8000, в пилоте – свыше 2000.

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

• Средой описания архитектуры в 1С:СППР на проекте пользовалось порядка 550 пользователей, на регулярной основе – 80-100. Но, конечно, СППР – это не та система, которая содержит в себе какие-то серьезные проблемы производительности. Там закрывать месяц и считать себестоимость не надо. Это справочники, справочники и еще раз справочники. Поэтому она может потянуть любой объем и разный состав участников – будь то подрядчики, заказчики, вендор, субподрядчики и так далее.

Информационные кризисы и механизмы СППР 2 по их предотвращению. Применение основной функциональности

Задача гигиены предотвращения информационных кризисов – это то, что СППР позволяет делать на уровне «мойте руки перед едой». Выделяют 4 вида информационных кризисов.

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

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

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

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

Т.е. если первые три информационных кризиса можно решить с помощью почтового клиента, то СППР, как и любая система учета на СУБД, позволяет решать все четыре кризиса – это позволяет повышать эффективность работы.

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

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

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

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

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

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

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

СППР содержит два механизма для перехода от базы данных к базе знаний:

1. Механизм загрузки объектов метаданных и использование привязки к ним. СППР позволяет загрузить объекты метаданных в информационную базу и отслеживать связи между ними – по аналогии с возможностями конфигуратора «Поиск по ссылке» или «Поиск ссылок на объекты». В СППР есть то же самое, но в гораздо более удобном виде – у вас получается «карта местности».

2. Механизм загрузки функциональной модели и использование привязки к ней. Это справочник «Функции» (или «Функции системы» в 1С:СППР 2), куда мы применительно к схеме Санкт-Петербурга можем загрузить маршруты транспорта или схемы метрополитена.

Когда мы связываем карту местности со схемой транспортных маршрутов, у нас получается что-то похожее на базу знаний, которая позволяет решить задачу «Прийти из точки А в точку Б».

Эти два механизма заточены именно на 1С. Именно это делает СППР инструментом, за который все так держатся. Потому что в нем это есть, и я не знаю других продуктов, где еще это есть в привязке к 1С.

Особенности документации 1С:СППР 2

Нестыковки все равно были, доработки все равно понадобились.

Какие у нас есть нестыковки:

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

2. Границы системы с точки зрения методики, заложенной в СППР 2. Изначально СППР 2 предназначена для документирования разработки тиражных решений. Когда разработчик разрабатывает тиражное решение, у него нет возможности связывать разрабатываемые объекты с внешним миром, поэтому в СППР функциональная модель не привязана к процессам заказчика. Она привязана именно к внутренней логике самой проектируемой системы. И процессы заказчика туда вручную вносить очень тяжело, хотя можно.
   Мы все проектные решения и документацию, собранную по процессам заказчика на этапе сбора требований, внесли как приложенные файлы к справочнику «Процессы». Получилось удобно. У нас справочник «Процессы» – это процессы на предприятии заказчика, и в присоединенные файлы этого справочника мы прикрепили:

   • pdf-схему процесса из Aris;

   • файл Word с описанием проектного решения;

   • и Excel для сопутствующих таблиц – все в одном месте.

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

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

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

Программное и аппаратное обеспечение

Вкратце о программном и аппаратном обеспечении, которое использовалось на проекте.

• Сервер приложений 1С для системы крутился на Windows;

• сервер СУБД – на Linux;

• платформа – 8.3.17;

• СУБД – PostgreSQL.

В пользу размещения сервера 1С на Windows есть много аргументов. Не так давно в одном из Telegram-каналов было обсуждение о том, что если вы разворачиваете СППР, СУБД может быть на PostgreSQL на Linux, но сервер приложений должен быть на Windows.

У нас сервер приложений был не сильно нагружен, а сервер СУБД с файлами базы СППР находился в «не ответственном» месте вместе с базами разработчиков – его можно разместить таким образом.

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

Действия команды проекта по устранению нестыковок и доработке продукта

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

Доработок пришлось делать много. На слайде основная доработка.

• Слева на рисунке показано, как описывается функция системы «Регистрация поступления безналичных ДС» в СППР редакции 1.0.

• А справа – как описывается функция системы «Поступление безналичных ДС» в СППР редакции 2.0.

Мы внедряли ERP.УХ, и готовая модель метаданных для нее предназначена для загрузки в СППР редакции 1.0. При этом на проекте использовался СППР редакции 2.0.

Поэтому мы были вынуждены сделать даунгрейд механизмов и структур хранения функциональной модели с СППР редакции 2.0 до 1С:СППР редакции 1.0.

Расскажу о других действиях команды проекта по доработке продукта.

Я уже говорил о необходимости описания в базе знаний маршрутов. Мы не ограничились описанием маршрутов через «Функции системы», где процесс заказчика был описан практически в виде маршрута «Как доехать из точки А в точку Б».

Второе место, где были описаны ориентированные связи – это справочник «Технический проект»:

• здесь через процессы раскрывались функции;

• из функций раскрывались объекты данных;

• из объектов данных раскрывались профили пользователей – это бизнес-роли;

• из профилей пользователей мы получали метаданные.

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

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

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

На слайде показан график работ в 1С:СППР 2 с привязкой к начальным этапам проекта.

СППР на данном проекте появилась на этапе рабочего проектирования, и с этого момента она начала активно развиваться.

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

Вместо заключения

СППР помогла нам решить наши задачи.

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

Но на самом деле, СППР нужно развивать под автоматизацию рутины. Для этого нужно дорабатывать:

• интерфейсы;

• правильные названия справочников;

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

И дальше уже в СППР можно вписать всю ту рутину, которая у вас есть на проекте – например, управление инфраструктурой.

Но начать лучше все-таки с интерфейсов и с правильных названий справочников.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.