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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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