Сервис-ориентированная архитектура. Цифровая копия бизнеса

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

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

Мы учим не разделять IT-сервисы с оргсхемами и согласовательными бизнес-процессами.

Представьте, что ваша организация только появилась на свет.

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

На инженерном языке вас можно назвать монолитом.

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

Вы бодро побеждаете проблему за проблемой - и «машинка едет».

Однако компания находится в режиме ручного управления.

Ваша компания растёт,и вместе с ней растут процессы.

Вы уже не размещаетесь в одной каморке, вы занимаете целиком здание.

Однако у вас еще нет оргструктуры, а без неё не может быть и сервисной архитектуры.

Процессы имеют всё больше нюансов, вероятность исполнения каждого нововведения уменьшается.

Машу за невыполненный пункт № 7 вашей инструкции по проверке договоров, потому что на ней держится десяток важных функций. Маша вам говорит: «Виновата, больше не буду».

В следующий раз, возможно, она и выполнит пункт № 7, но, вероятно, нарушит пункт № 9 и пункт №

Полномочия отделов и отдельных сотрудников всё ещё перемешаны.

Вам пока не нужно, чтобы людей было как минимум столько же, сколько функций.

Вы поделили так компанию, как казалось логичным - например, поделили по этажам, на которых сидят отделы.

Этот пример намеренно «притянут за уши».

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

Но всё ли из бухгалтерии вы теперь можете требовать именно у бухгалтерии?

Руководитель на работе с утра до ночи, не отходит от ноутбука и телефона ни в отпуске, ни на выходных просто для того, чтобы «всё нормально работало».

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

По красивой картинке у вас оргсхема предприятия.

По факту у вас по-прежнему монолит.

Монолит - это такое состояние организации или программы, при котором каждое новое расширение функционала стоит дороже, чем предыдущее.

На каждое следующее изменение требуется всё больше сервисных действий.

Доходит до того, что у вас растёт количество людей, а прибыль нет.

Монолитная IT-архитектура абсолютно такая же.

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

Безусловно, ваша компания с плохо поделенными отделами (в IT это называют сильной связанностью) может как-то жить.

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

Каждый из команды понимает логику до какого-то предела.

Но чем дальше, тем сложнее понять, что именно нужно сделать.

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

Реакции многих руководителей и инженеров в этой ситуации очень похожи.

Руководители читают Harvard Business Review, слушают модные конференции и

Грефа - и узнают про Agile, про бирюзу или про какое-то супер-пупер решение, которое систематизирует ваш бизнес и сделает всю работу за них. «О боже, существует какая-то волшебная таблетка, которая все решит!»

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

Но выделять по наитию нельзя - как в бизнесе, так и в IT.

Более того, IT нужно делить ровно по тем же границам, как и бизнес.

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

Сервис - это не какое-то магическое заклинание, которое вроде как лучше монолита, но хуже микросервиса.

Сервисная архитектура - это карта функций ваших систем, разбитых на бизнес-блоки.

Сервис определяется в парадигмах ценного конечного продукта или в определениях выхода процесса в процессном управлении.

На выходе должно быть предельно ясно и прозрачно, что именно у этого сервиса «покупает» другая компания (или другой отдел в рамках вашей компании). Например, посмотрим на организационную схему Хаббарда.

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

Этот отдел будет ответственным за свой конечный продукт тогда и только тогда, когда у него будут все полномочия по исполнению ЦКП. HR-отдел должен работать в своей изолированной IT-системе ровно для того, чтобы самостоятельно управлять нужными изменениями. Важно, чтобы HR-отдел выдавал в вашу организацию лишь то, что является его ЦКП. В реальном мире это сотрудники, а в мире IT - цифровая копия сотрудника.

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

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

Если завтра HR-отдел сменит свою программу 1С на облачный сервис, то единственное, что он должен сделать, - поменять в шине правило того, как обращаться к досье сотрудника.

Это часть полномочий HR отдела наравне с рекрутингом и вводом сотрудников в должность.

Ведь цифровая копия сотрудника - это тот же самый сотрудник, только в цифровом виде.

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

Это ситуация распространённая и понятная: айтишникам интересно пробовать что-то новое и модное, что можно «положить в портфолио».

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

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

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

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

Не IT живёт по правилам бизнеса, а остальные отделы живут по правилам IT.

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

Точно так же, как неправильное разделение отделов влечет к конфликтам между отделами и непрозрачным принятиям решений.

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

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