Роль ИТ-управленцев и как она связана с качеством ИТ-архитектуры компании

14.03.24

Бизнес-процессы - Оптимизация бизнес-процессов

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

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

 

Как ИТ-департамент превращается в «черную дыру»

 

Начнем с предыстории: как вообще развивались информационные системы?

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

Что происходит, когда ИТ начинает расти? Как получается вот такая «ромашка», в центре которой – ИТ, поглощающее все вокруг, как чёрная дыра?

 

 

Чем больше в ИТ-системе бизнес-процессов без организационной перестройки, тем больше в этом удельный вес и авторитет ИТ-департамента. Со временем другие отделы становятся неявными подчиненными ИТ-директора или технического департамента. Технический департамент оказывается в роли «папочки», а вокруг «нерадивые дети» – HR, продажи и так далее – все пользователи, которые стремятся что-то разрушить.

 

Треугольник компетентности

 

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

 

 

Разберем виртуальный кейс:

Есть три отдела, которые работают в двух системах: два отдела работают в CRM, третий – в ERP.

 

 

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

 

 

Оказывается, что до конца никто не компетентен в своей рабочей системе. Никто, кроме ИТ-департамента – это первый шаг превращения ИТ-отдела компании в «черную дыру».

Полноты знаний ни у одного из отделов нет. Контроля – тоже нет. Может ли отдел продаж поменять CRM-систему? Нет, не может. Каждое изменение становится вызовом для отдела.

 

Знания о системе и качество данных

 

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

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

Но если у нас неправильно нарезанная система, гипертрофирован ИТ-отдел, то отдел продаж может сказать:«Я не могу ничего поправить. Я не знаю. У меня есть два ООО "Ромашка" – может быть, вторая компания мне не нужна, но нужна коммерческому отделу. Я не могу отвечать за качество данных».

 

 

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

 

Количество и стоимость функционала

 

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

 

 

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

Нужно ли ждать у конечного пользователя рвения в изменении своих систем, когда он чувствует, что некомпетентен, что любое изменение становится слишком трудоемким и дорогим?

 

Какой должна быть оргструктура и роль техотдела

 

Согласно Domain-Driven Design, оргструктура не может расходиться с контуром. Эту мысль в конце 60-х годов сформулировал Мелвин Конвей, сказав, что «организации проектируют системы, которые копируют структуру коммуникаций в этой организации».

 

 

Статью об этом Конвей отправил в Harvard Business Review, но ее отклонили. По мнению редакции, автор не доказал, что если оргструктура и ИТ-структура расходятся – будут проблемы. Через 20 лет статью опубликовали: накопились доказательства и пришло осознание того, что если оргструктура не соответствует ИТ-контуру, все идет очень плохо.

Должно быть как-то так: у каждого отдела есть свой маленький ИТ, где есть знания, ответственность и контроль.

 

 

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

 

 

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

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

 

Как построить гибкий IT-контур

 

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

 

 

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

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

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

Когда ИТ-департамент появляется и говорит: «Я вам сейчас улучшу», найдется миллион поводов объяснить, почему это улучшение плохое. Людям будет неудобно, потому что не они это выбирали.

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

 

Роль технического департамента

 

Встает вопрос, а какая роль технического директора, технического департамента?

 

 

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

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

 

 

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

 

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

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

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Оптимизация бизнес-процессов Взгляд со стороны Заказчика Внедрение изменений Платформа 1С v8.3 Бесплатно (free)

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

13.08.2024    818    0    avermakov1986    5    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. DemetrKlim 178 14.03.24 15:06 Сейчас в теме
2. sereginseregin 22 15.03.24 08:26 Сейчас в теме
По мнению редакции, автор не доказал, что если оргструктура и ИТ-структура расходятся – будут проблемы.


"А вы, друзья, как ни садитесь,
Всё в музыканты не годитесь" (Крылов И.А.)

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

То, что сейчас приято, например, банковские и складские системы делить на разные ИТ команды-микросервисы в соответствии с оргструктурой предпрития - это несовершенство нашего понимания системы управления. Принципы контроля норм, ответственных, сроков, приоритетов и исполнения во всех системах одинаковый. Различные только названия объектов управления (деньги и материалы). ИМХО время ещё первобытное, поэтому на каждую задачу кидают индивидуальную команду, которая решает поставленную задачу своим уникальным методом.
3. starik-2005 3080 15.03.24 11:58 Сейчас в теме
(2)
решает поставленную задачу своим уникальным методом
Так всем же известно, что у одной и той же задачи есть множество решений с той или иной эффективностью (количество затрат деленное на созданную ценность). И если какая-то команда вспомнила с институтов какую-нить приличную теорию управления, заменив ей исторически сложившийся хаос - честь ей и хвала. Но уповать на то, что эта система в данном конкретном случае самая эффективная - это тоже не от большого ума. Искать решение лучше - это и есть часть той великой работы, которая делает компанию управляемой и предсказуемой, но при этом способной резко вырасти за счет обнаруженного методом такого вот поиска ноу-хау. Ведь если делать все время то, что делали все время, потому, что все время делали так - это слабый аогумент.
4. sereginseregin 22 15.03.24 14:03 Сейчас в теме
(3)
Так всем же известно, что у одной и той же задачи есть множество решений с той или иной эффективностью


В контексте статьи я имел ввиду, что по разному решаемые задачи могут иметь общий вариант решения (можно создать общую универсальную ИТ систему, чтобы управлять деньгами на счетах и материалами на стеллажах), в этом случае структура ИТ не будет и не должна повторять структуру предприятия.
5. starik-2005 3080 16.03.24 14:09 Сейчас в теме
(4) Практика показывает, что все униварсальное сложнее, чем заточенное под конкретный процесс. Типовые универсальны, но приходится их допиливать под конкретный бизнес. Иначе нас (1С-негов) не существовало бы.
6. sereginseregin 22 20.03.24 01:33 Сейчас в теме
(5)практика показывает, что целевой аудиторией любых универсальных решений являются специалисты с пониженными техническими навыками, чем предыдущее поколение. Там где 1С-ниги внедртли десяток вариантов проведения документов (потому что пользователи сами не знают чего хочуть), аналитики без навыков программирования договорятся с пользователями об едином универсальном документе и простом алгоритме проведения. Проблема в воспитании таких аналитиков, демонстрации им всего многообразия, чего наплодили 1С-ниги, ибо те не ведали, что творили....
7. starik-2005 3080 20.03.24 09:56 Сейчас в теме
(6)
ибо
Множество документов в той же ЕРП - это компромисс между сложностью, скоростью и функционалом. Способность ЕРП к отражению произвольного учета от первичных документов - это универсальность, но даже приличные консультанты до конца не знают всей этой специфики. А бизнес хочет всего и сразу, разрешая такие компромиссные решения. Суть аджайла в том, что лучше работающее что-то, чем идеальный неработающий конь в вакууме, за который так топят "просвещенные" умы. И из любого куска материала не создается сразу бюст товарища Сталина - сначала оттуда убирается все лишнее. Это процесс, который не остановить. Но результата этот процесс достигает далеко не сразу.
8. sereginseregin 22 01.04.24 08:05 Сейчас в теме
...А бизнес хочет всего и сразу, разрешая такие компромиссные решения...лучше работающее что-то, чем идеальный неработающий конь в вакууме...


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

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