Архитектура цифровых платформ. От настоящего к будущему - страница 6

уровне. Да, в случае простого продукта можно составить продуктовую команду, отвечающую принципам гибких практик, но современные продукты (а особенно если речь идет о кросс-продуктах) крайне сложны, требуют привлечения специалистов разных компетенций. А потому даже на одном уровне автоматизации (при приведенном выше примере принципиально различных технологических и организационных требованиях к базису каждого) может оказаться весьма затруднительным собрать единую команду гибких практик, развивающую соответствующий продукт. После чего возникнет необходимость синхронизации работы команд для обеспечения качества создаваемого продукта, дабы последний не стал подобен лоскутному одеялу из слабо связанных между собой доработок, что в свою очередь может повлечь как рыночную слабость продукта, так и нарушение непрерывности его предоставления. При этом команда развития каждого уровня автоматизации продукта реализует требуемые доработки с разной скоростью, зависящей от функциональной и нефункциональной составляющей, например:

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

• Различный технологический базис уровней автоматизации приводит к разной скорости их развития в соответствии с нефункциональными требованиями.

Добавим сюда еще и возможное попадание в ментальную ловушку, рассмотренную в главе «Архитектуры цифрового мира», посвященной цифровым платформам, а именно создание выделенных команд разработки и развития платформ. В случае масштабирования указанной ошибки на рассматриваемую в примере организацию может оказаться вероятным, что продукт разрабатывается набором команд гибких практик разработки, при этом для каждой платформы в организации существует отдельная команда развития. Получается, что в общем случае (при условии высокой сложности автоматизируемого продукта) мы можем столкнуться с ситуацией, при которой в реализации значимой продуктовой доработки могут быть задействованы до восьми (!) команд разработки. Синхронизация их деятельности становится весьма нетривиальной задачей. И даже совмещение платформенных и продуктовых команд в отдельных случаях (например, это вполне возможно для случая автоматизации функций синтетического учета) не привносит принципиального упрощения ситуации. И стоит учесть, что в рассматриваемом примере мы сознательно учитывали относительно простую структуру как продукта, так и организации. Последняя может внедрять еще и «платформу CRM», и расширяющую «омниканальную платформу» «платформу» ДБО, к примеру, и «платформу MDM», и многие другие аналогичные «платформы».

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