Шоукейс использования iServer на предприятии Scottisch Water

Какой самый современный и многообещающий метод в той работе, которой я сегодня занимаюсь существует в мире? И использую ли я его? Этот вопрос внезапно поднимает другую, возможно неожиданную проблематику - вопрос о том, чем же я вообще сегодня занимаюсь? Для ответа на него мне пришлось провести некоторое расследование. Читай его здесь.

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

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

Но тем не менее на рынке есть предприятия, которые предлагают целостные решения для инженерии предприятия. И очевидно есть предприятия, которые их продукт покупают и эксплуатируют. Одним из таких продуктов является софт под названием iServer от Orbus Software. И одним из их клиентов является Scottisch Water. И нет, к сожалению речь идёт не о производстве виски, а действительно о фирме в госведении Шотландии, которая занимается обеспечением населения водой из под крана. И шеф их команды по инженерии предприятия, Паул МакДуглас дал интервью интересному ресурсу SearchCIO на предмет боли и радости внедрения и использования iServer. Читать можно здесь.

Что-же рассказывает Паул? Внимание, читаю между строк.

Говорит, что для дигитальной трансформации фирма проснулась в 2011ом году, потому что стало очень сложно менеджерить сотни разных используемых разными отделами технологий. И при этом очень хотелось понимать, какой эффект на предприятия имеют те или иные трансформации.

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

Для управления изменениями и мониторинга стека они взяли себе iServer. Несмотря на намекающее название, тулза живёт в экосистеме Майкрософта и дружит с Office365, Teams и Power BI. По тяжелому голосу Паула слышно, что есть какая-то боль со стоимостью лицензий - он упоминает, что они стараются держать их количество низким.

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

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

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

Заметно, что нигде в интервью Паул не упоминает само снабжение граждан водопроводной водой. Складывается впечатление, что он не видит своей целевой системы или не считает важным держать её в фокусе внимания, говоря о дигитальной трансформации и инженерии предприятия. Несистемный чувак.

И ещё параллельно рассказывает другую очень интересную историю. Описанные выше две команды были основаны в 2011ом году. Пишет что у них была большая монолитная махина изменений. Надо полагать, что iServer является частью её. Всё это было очень тяжеловесно и внедрения длились годами. В связи с чем в 2019ом году они собрали ещё третью команду, занимающуюся экспериментальным внедрением легковесных технологий на местах. Вот там уже речь о молодой команде, работающей по аджайлу. Эта команда находит дешёвые, лёгкие решения для нужд отделов, для того чтобы закрыть их потребности и создать - цитата - "временные или постоянные решения". Ну то есть похоже в обход тяжеловесной махины создаются и на постоянной основе используются гибкие решения, пока тяжеловесные энтерпрайс-инженеры не придумают как это прикрутить к их системе отчётов.

Я посмотрел немного в демки iServer. Там к сожалению демонстратор делает ошибку использования каких-то рандомных данных, которые не вяжутся в реальное предприятие из крови и плоти, меняющее что-то в реальном мире. Что я смог для себя подметить, это что менеджеры отделов могут/должны репортить в систему о структуре их отделов, изменениях в структуре и текущих проектах. Для их удобства есть интеграция с Microsoft Teams. Про интеграцию со Слеком что то умолчали. Особенно порадовала возможность/требование вбивать в систему оценку здоровья того или иного звена - от 1 как очень плохо до 5 как очень хорошо.

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

Федор, читаю Атул Гаванде. Чек-лист. Так вот там важная мысль на примере стройки и строительной организации (большая, куча людей и процессов, оргзвеньев, подрядчиков и тд). А именно: “Основным достижением строительной науки за последние десятилетия было совершенствование контроля за коммуникацией”. Очень сопереживаю этой мысли и я. Выстраивание, налаживание, контроль коммуникаций и координации - основная задача в коллективах, туда и менеджерский фокус должен быть направлен. Мой личный опыт это подтверждает полностью. Более того, при более детальном рассмотрении, даже “процессные, продуктовые, железные” ошибки были результатом коммуникационно-координационных ошибок.

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

а причем тут коммуникации, если софт вроде бы про архитектуру предприятия? убежал Федор вперед на пару недель, перевыполняет план по постам ))

ему-то хорошо писать, но я вот никак не могу прокомментировать сабж, ибо еще с управлением ЖЦ не уложилось - а тут уже арх. предпр.

“а причем тут коммуникации, если софт вроде бы про архитектуру предприятия?”

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

Это как выстраивать архитектурную схему нейронов, не рассматривая нейронные связи.

Да, ну если совсем намудрить то можно выдвинуть мысль что коммуникация это функциональная часть воплощения предприятия, в то время как архитектура - это его описание. Я Пауля читаю так, что с архитекурой у них всё в порядке. Вот сделать так, чтобы архитектура совпадала с реальными работами людей - сложно. И тут начинается коммуникация.

В организации должны быть люди, которые спросили всех об их практиках и интерфейсах и сказали, как можно (нужно/удобно) наладить связь. Этот процесс должен быть итеративный и (желательно) постепенно разворачиваемый в организации.
Почему руководители больших организаций делают ставку на тот или иной поддерживающий продукт, вопрос. Почему они при этом перестают говорить о потребителях и удовлетворении их потребностей, вполне понятно - трансформация отнимает все силы. А услуги? Ну, оказываются. Какой толк жаловаться на монополию?
Пример про молодую компанию “надстройку” напомнил мне пример эволюционного развития, о котором я услышал от Сапольски: чтобы согнуть один, например, указательный палец руки у человека проходит два сигнала: 1) согнуть все пальцы 2) при этом не сгибать все пальцы, кроме указательного. Механизм сгибания пальцев млекопитающих устроен таким образом, что они могут либо все сгибать, либо все разгибать. И чтобы не придумывать отдельный механизм для сгибания отдельных пальцев, у людей к общему принципу “1” эволюционно развилась надстройка “2”.
Но это природа, и на такие “надстройки” у неё уходит миллионы лет. Почему люди боятся начинать правильные изменения в своих компаниях, им виднее.