Импортозамещение QMS
Российских систем класса QMS практически нет (в мае 2024 в Москве демонстрировалось отечественное решение АИСМК, новость см. здесь, подробнее будем изучать). О причинах смотри статью о степени зрелости рынка. Иностранные системы ушли с нашего рынка. Написать собственную систему на традиционной архитектуре нереально и, наверно, нецелесообразно. Однако в текущей ситуации проще построить систему на технологиях микросервисов вместо громоздкой монолитной системы. Это и быстрее, и дешевле, и можно реализовывать не все сразу.
Так уже делается даже для ERP. Примером может быть Odoo. Odoo — это набор программных инструментов для управления бизнесом, включая, например, CRM, электронную коммерцию, выставление счетов, бухгалтерский учет, производство, склад, управление проектами и управление запасами. Есть бесплатная версия (так называемая комьюнити), распространяемае под лицензией GNU LGPLv3. ODOO — это процессно-ориентированная система (в отличии от 1С, которая является документоориентированной системой) в которой реализованы типовые основные и вспомогательные процессы практически любой компании. И если компания не имеет описанных и утвержденных процессов, она спокойно может взять уже заложенные в систему процессы.
То же и для PLM. Архитектура микросервисов в отчете компании Cognizant 2019 года названа одним из трендов развития PLM систем в эпоху цифровой экономики. Основным достоинством этой архитектуры является более простое обновление системы и добавление нового функционала. В монолитной PLM системе обновление – это длительный и дорогостоящий процесс. Эту же тенденцию отмечает один из гуру PLM Олег Шиловицкий в статье аж 2016 года: "Существующие PLM-платформы возвращаются на 15-20 лет назад в жизненном цикле разработки и многочисленных приобретений. Эти платформы в основном представляют собой монолитные приложения и серверы, полагающиеся на архитектуру базы данных для хранения и управления данными. Одной из самых больших проблем существующих архитектур является переход от одного продукта к другому или обновление существующих продуктов. Монолитный характер применения делает эту проблему очень болезненной. Новые облачные архитектуры могут предоставить альтернативу, принеся набор микросервисов и заменив существующий продукт".
Часто среди тенденций развития ИТ систем упоминаются облачные технологии. А эта тема плохо ложится на российскую специфику. Так вот микросервисы могут быть реализованы как в облаке, так и без него. Т.е. подразумеваем сетевое, но не облачное решение.
Далее кратко рассмотрим особенности монолитной архитектуры и архитектуры микросервисов. Изложим это ориентируясь на архитектора цифровизации предприятия или CDO.
Монолитная архитектура — это традиционная модель программного обеспечения, которая представляет собой единую систему, работающую автономно и независимо от других приложений. Монолитом часто называют нечто большое и неповоротливое, и эти слова хорошо описывают монолитную архитектуру для проектирования ПО. Монолитная архитектура — это отдельная большая вычислительная сеть с единой базой кода, в которой объединены все бизнес-задачи. Чтобы внести изменения в такое приложение, необходимо обновить весь стек через базу кода, а также создать и развернуть обновленную версию интерфейса, находящегося на стороне службы. Это ограничивает работу с обновлениями и требует много времени.
Микросервисная архитектура (MSA) представляет собой метод организации архитектуры, основанный на ряде независимо развертываемых служб. У этих служб есть собственная бизнес-логика и база данных с конкретной целью. Обновление, тестирование, развертывание и масштабирование выполняются внутри каждой службы. Микросервисы разбивают крупные задачи, характерные для конкретного бизнеса, на несколько независимых баз кода. Микросервисы не снижают сложность, но они делают любую сложность видимой и более управляемой, разделяя задачи на более мелкие процессы, которые функционируют независимо друг от друга и вносят вклад в общее целое.
И сейчас самое время сказать как такая архитектура влияет на работу аналитика проекта. Систему в этом случае не получится рассматривать как чёрный ящик, где аналитик определяет требования к результату "на выходе". Потому что "на выходе" тут - это на границе каждого микросервиса и все эти границы надо проектировать и определять.
Таким образом, с точки зрения анализа систему с MSA можно рассматривать как десятки небольших систем и интеграций между ними. То есть задачи схожи с работой над любой интеграцией. Но есть один нюанс - интеграций много и они меняются при каждой доработке, вслед за малейшим изменением логики или данных. Однако этот подход не требует жесткой модели данных, характерной, например, для монолитных PLM систем.
В менеджменте качества речь всегда идет о процессах, там их много, они взаимосвязаны, но каждый в отдельности не слишком сложный. Это идеально ложится на идеологию микросервисов.
Вторым доводом упомянем степень зрелости. Если компания на данном этапе не готова внедрять сразу 10-15 модулей классической QMS, то можно вести разработку поэтапно. Например, практически у всех актуально управление рекламациями. Часто для их обработки используется процедура 8D. Но практически нигде это явно не связано со стадиями разработки продукта или процесса. В классической QMS связь идет от несоответствий к анализу рисков по методике FMEA, а FMEA является основой для обоснования внесения изменений (по крайней мере для автопрома, где актуален стандарт IATF 16949).
Другие доводы рассмотрим в отдельной статье - здесь.
