ДРАКОН – практика разработки и поддержка 1С:ERP командой подрядчиков и командой заказчика. История одной задачи

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

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

История создания нотации ДРАКОН. Космические технологии – в бизнес

Немного о том, что представляет собой язык ДРАКОН, какие он технологии использует и на каких программах работает.

В 1976 году в СССР в обстановке строжайшей секретности началась разработка многоразового транспортного космического корабля Буран. Это был грандиозный проект, в создании которого принимали участие 86 министерств и ведомств и 1286 предприятий СССР (всего около 2,5 миллиона человек).

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

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

Чтобы решить проблему нехватки программистов, институт прикладной математики РАН создал два русскоязычных языка программирования:

• язык реального времени ПРОЛ2 для разработки бортовых комплексных программ (автор Виктор Крюков);

• язык для разработки программ наземных испытаний ДИПОЛЬ (автор Владимир Луцикович);

И в Пилюгинском центре под руководством Константина Федорова был разработан язык ЛАКС для моделирования различных ситуаций.

Таким образом, появились три новых языка: ПРОЛ2, ДИПОЛЬ и ЛАКС.

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

При том, что задачи у них одинаковые:

• При автоматизации бизнес-процессов нужно соединить специалистов из разных областей и согласовать все с ними в едином поле.

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

Вот в 1986 году, когда руководство проекта «Буран» поняло, что три языка избыточны и дублируют друг друга, их было решено заменить одним языком.

И Владимир Параджанов, в то время начальник лаборатории комплексной разработки вычислительных систем, придумал единый язык для всех и назвал его ДРАКОН. Расшифровывается он как Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность.

«Буран» слетал, все нормально. Летал в беспилотном режиме, как вы знаете. На Байконуре он приземлился на специально выделенный космодром, и программный комплекс показал себя на «отлично».

Язык ДРАКОН решает следующие задачи.

В первую очередь, он визуализирует информацию – помогает людям с ней освоиться, погрузиться в тему, запомнить ее и понять.

Язык ДРАКОН позволяет одинаково хорошо описывать любой алгоритм – будь то бизнес-процесс или код программы, и все это в едином информационном поле.

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

• На первом уровне мы можем составить концепцию бизнес-процесса для руководства – как это примерно должно работать.

• На втором уровне мы можем составить инструкции пользователей.

• И третий уровень – это уже уровень самого кода программного решения. Там, где вся логика того, как написали программу, раскладывается уже до строчки программного кода.

Язык упрощает восприятие сложных проблем – делает непонятное понятным.

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

Также язык упрощает взаимодействие между представителями различных ведомств.

Напомню, что в проекте «Буран» принимало участие около 2,5 миллиона человек различных уровней: ведомства, институты и так далее. Точно так же у нас в Газпроме тоже очень много ведомств, департаментов, которым нужно согласовывать документы между собой, находить общий язык, у каждого свои интересы и свой уровень компетенций и знаний.

При использовании единой нотации уменьшаются проблемы взаимного непонимания между сотрудниками различных специальностей. В таких условиях язык ДРАКОН становится единой языковой средой. Можно вспомнить библейскую историю о Вавилонской башне, когда строительство шло успешно, пока люди говорили на одном языке, а затем, когда языки перемешались, башня чуть не разрушилась.

И плюсом – у программистов кардинально улучшается качество программного обеспечения по критерию понимаемости.

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

Мы работаем в редакторе «ИС ДРАКОН», который выгладит примерно так, как на слайде.

В отличие от других нотаций в языке используется всего 4 блока. Но этого достаточно.

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

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

Хотя этот редактор и довольно старый, у него есть ряд преимуществ:

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

• Автоматическая проверка логики построения схем.

• Генерация кода с поддержкой мультиязычности – он поддерживает не только 1С-язык, но и другие языки. Там можно составлять схемы на ABAP/4, это SAP-овский язык, на Java, на C+, на C#, на Gherkin – на чем угодно.

• Поддержка версионирования моделей схем.

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

• Хранение ссылок на сторонние материалы – можно подключать таблицы, документы и т.д.

• Поддержка изображений.

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

Как придумать решение на основании собранных функциональных требований

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

Я стараюсь обобщить всю эту информацию в ДРАКОН-схеме, после чего мы собираемся с командой бизнес-аналитиков, заказчиков и программистов, чтобы обсудить, как все это будет функционировать.

На слайде – конкретная задача, которая у нас была.

В 2021 году нам нужно было перейти в 1С:ERP на ФСБУ 6/2020 по учету основных средств. Фирма «1С» анонсировала выход обновления с механизмом, который бы позволил автоматизировать этот переход, к Новому году. Но в долгожданном обновлении возможности автоматизированного перехода не оказалось – вместо этого фирма «1С» предложила вбивать все эти данные в документы вручную.

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

А теперь представьте, что вы подрядчик, который получил такую задачу, и вам надо сказать заказчику: «Мы напишем этот механизм за столько-то времени».

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

В итоге нам нужно было выгрузить все данные по основным средствам из 1С в Excel, рассчитать их там и перебросить обратно в ERP.

После первого мозгового штурма мы сформулировали для себя следующие задачи:

• Сделать механизм перехода по требованиям бухгалтерии.

• Пересчитать на этом механизме 2021 год.

• Реализовать механизм «межотчетного периода» – тогда о таком механизме вообще никто не слышал. Это когда вы после закрытия декабря должны перед январем сделать переход на ФСБУ 6, и уже с января считать по ФСБУ 6. Сейчас фирма «1С» сделала такой механизм и назвала его «межрасчетный период».

• Далее – закрыть первый квартал 2022 года.

• И повторить все это в рабочей базе.

На все это, как вы помните, у нас был месяц.

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

• Зеленым цветом помечены этапы ввода первичной документации.

• Красным – блок закрытие месяца.

• И после закрытия месяца здесь описаны отчеты, которыми бухгалтерия проверяла корректность ввода данных по основному средству – в данном случае мы формировали карточку учета по основному средству и «Справку-расчет амортизации».

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

Рассмотрим первый шампур подробнее. Здесь блок, выделенный красной рамкой – это переход на тот итоговый алгоритм, который у нас должен был запустить процесс перехода на ФСБУ 6. Это точка входа в нашу задачу.

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

Читается эта схема по заголовкам – слева направо и сверху вниз. Состоит из основных этапов:

• скорректировать амортизацию по основным средствам стоимостью больше 100 тысяч рублей;

• списать на расходы основные средства меньше 100 тысяч рублей;

• и списать компоненты основных средств с хоз. инвентарем.

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

Где и как ДРАКОН-схемы помогут нам написать код 1С. Как превратить код в бизнес-процесс

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

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

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

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

Здесь красным выделен блок функциональности, который мы подсмотрели в 1С:Бухгалтерии и реализовали в 1С:ERP.

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

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

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

Второй шампур говорит о том, что для того, чтобы перейти на ФСБУ 6, бухгалтер должен ввести стандартный документ «Изменение параметров ОС» – для ввода этого документа есть свои инструкции.

А третий шампур описывает документ «Переход на ФСБУ6», который мы написали для операции перехода.

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

И последний четвертый шампур показывает, как мы будем проверять результат наших действий. В данном случае, мы формируем по выбранным основным средствам отчет «Справка-расчет амортизации» и проверяем обороты счета 02 и 84

В этой части обозначена логика формирования движений по регистрам.

И здесь – выход на схему с куском кода, который в итоге обрабатывает эту бизнес-логику .

Получается, что слева на схеме описано техзадание, а справа – сам код программы. В данном случае, на код процедуры проведения документа.

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

С одной стороны, может показаться, что работать с кодом в виде схемы долго, но на самом деле, если специалист имеет опыт работы с ДРАКОН-ом, то он справится с задачей даже быстрее, чем если бы вы писали код в конфигураторе.

Мы проверяли на практике: брали обработку, требующую изменений, передавали её автору, а одновременно подключали программиста, который впервые сталкивался с этой обработкой, но имел опыт работы с ДРАКОН-ом, чтобы он разобрался в коде и адаптировал его под новые функциональные требования.

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

А когда код делается в ДРАКОН-е, там сразу строится визуальная структура, и программист отсеивает уже на этапе кодинга те логические ошибки, которые он бы отсеивал в процессе тестов, в прогоне итераций. Это сокращает время разработки в разы.

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

Сам код хранится в схеме – он собирается поблочно и переносится в конфигуратор за пару минут обычным копипастом. А в схеме вы его просто анализируете.

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

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

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

Я управляю командами подрядчиков, и мне периодически нужно проверять код, который приносят наши подрядчики. Для этого я использую ДРАКОН-схемы.

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

Но в данном случае мы эту ошибку оставили, потому что ее нужно показать на этой презентации. А во-вторых, мы ее оставили из-за того, что время разработки было ограничено, и переход на новый ФСБУ не касается текущей деятельности. Мы один раз этот переход проведем, а больше к нему возвращаться не будем. И для того, чтобы не тратить время на замену цикла на запрос, мы уже оставили эту ошибку.

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

Здесь хранится сам код, отсюда он копипастится.

И переносится в саму процедуру.

Здесь показан линейный способ переноса – без GOTO, который всех пугает.

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

В итоге:

• Используется единая логика языка ДРАКОН – от концепции бизнес-процесса и инструкций пользователя до интерфейса.

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

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

Как протестировать. Смотрим, что получилось. Исправляем ошибки

Дальше кратко про тестирование.

Вы можете заменить язык 1С и на уровне инструкций пользователя вписать в эту схему Gherkin – выгрузить код в Vanessa Automation, и получить готовый автотест, чтобы прокатывать его перед каждым обновлением.

Сценарии у нас уже готовы – это схемы бизнес-процесса.

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

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

В итоге:

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

• Схемы для тестов мы строим в редакторе «ИС ДРАКОН» – они все хранятся в одном месте.

• Для тестирования используем язык Gherkin и в результате получаем готовый автотест.

• При актуализации схемы, тесты будут актуализироваться автоматически.

Как научить. Инструкции пользователям. Составляем, рассказываем, показываем

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

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

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

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

Лучшее техническое задание – это, как вы знаете, готовая инструкция на выходе.

Инструкции в виде схем всегда актуальны, потому что это часть разработки.

Как развивать. Новые задачи, новые возможности, новые вызовы

Процесс развития бизнес-процесса при использовании нотации ДРАКОН происходит точно так же, как обычно.

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

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

Но в этой схеме уже указано, что мы сделали переход на ФСБУ 6. И как мы это делали, там тоже есть. Мы через 5 лет откроем эту схему и увидим, как мы это делали.

В итоге:

• Работа со схемами ДРАКОН помогает адаптировать бизнес-процессы к изменяющейся ситуации – при изменении ключевых бизнес-процессов у вас рождаются требования к программному обеспечению.

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

Вопросы и ответы

Так за какое время вы в итоге написали этот механизм?

За две недели мы написали этот механизм, оттестировали и запустили – да, все новогодние праздники 24/7 просидели на работе, но все получилось. Это к вопросу о том, зачем вообще писать схемы, зачем этим заморачиваться.

Основным инструментом для доработки было написание схем?

Да, написание схем в ДРАКОН-е. В команде было три человека – я и два человека из команды подрядчика (бизнес-аналитик и программист). И еще была обратная связь у бухгалтерии, но она была очень занята. В итоге мы в таком авральном режиме с помощью координации именно на схемах быстренько все это запилили.

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

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