Существует много теорий о том, как выстроить взаимодействие между ИТ-отделом компании и всеми остальными структурами, в том числе – про жесткую силу: как бы так сделать, чтобы пользователи были замотивированы на изменения. Но давайте разберемся, откуда у бизнес-пользователей фундаментальные проблемы с мотивацией?
Как ИТ-департамент превращается в «черную дыру»
Начнем с предыстории: как вообще развивались информационные системы?
Когда компьютеры были большими и умели мало, а каналы связи были очень слабыми, компьютер воспринимался как некое дополнение к бизнес-процессам. Например, отдел логистики: у нас в системе отражаются только остатки, а вся остальная жизнь – какие-то накладные и так далее – идут в отрыве от информационной системы.
Что происходит, когда ИТ начинает расти? Как получается вот такая «ромашка», в центре которой – ИТ, поглощающее все вокруг, как чёрная дыра?
Чем больше в ИТ-системе бизнес-процессов без организационной перестройки, тем больше в этом удельный вес и авторитет ИТ-департамента. Со временем другие отделы становятся неявными подчиненными ИТ-директора или технического департамента. Технический департамент оказывается в роли «папочки», а вокруг «нерадивые дети» – HR, продажи и так далее – все пользователи, которые стремятся что-то разрушить.
Треугольник компетентности
Давайте разберем проблему противостояния ИТ-департамента и других отделов компании на примере треугольника компетентности. Итак, компетентность невозможна, если ты не знаешь про ту область, в которой должен разбираться, у тебя нет ответственности и контроля за изменениями.
Разберем виртуальный кейс:
Есть три отдела, которые работают в двух системах: два отдела работают в CRM, третий – в ERP.
Ни у одного из отделов нет полноты знаний о системе, в которой работают коллеги. Вплоть до того, что в другой системе клиент может называться не так, как привыкли сотрудники. Порождаются атрибуты, о которых не знают пользователи: можно их удалить или они нужны кому-то еще, другим пользователям?
Оказывается, что до конца никто не компетентен в своей рабочей системе. Никто, кроме ИТ-департамента – это первый шаг превращения ИТ-отдела компании в «черную дыру».
Полноты знаний ни у одного из отделов нет. Контроля – тоже нет. Может ли отдел продаж поменять CRM-систему? Нет, не может. Каждое изменение становится вызовом для отдела.
Знания о системе и качество данных
Другая проблема мотивации пользователей – некачественные данные. Чтобы справиться с этой проблемой, многие предприятия решаются на проекты по внедрению MDM-систем, чтобы обеспечить единство представления массивов справочных данных во всех информационных системах.
Если у отдела продаж есть дублирующиеся данные, логика простая: поправить бизнес-процессы так, чтобы в контур предприятия попадала правильная информация.
Но если у нас неправильно нарезанная система, гипертрофирован ИТ-отдел, то отдел продаж может сказать:«Я не могу ничего поправить. Я не знаю. У меня есть два ООО "Ромашка" – может быть, вторая компания мне не нужна, но нужна коммерческому отделу. Я не могу отвечать за качество данных».
В результате появляются MDM-системы – как некое противодействие, как исправление. Но при этом возникают другие проблемы, и не решается основная. Мы просто пытаемся исправить плохие бизнес-процессы программным продуктом, автоматизировать хаос.
Количество и стоимость функционала
Следующая история по поводу стоимости и компетентности в области каждого продукта. Чем больше у нас настроек, пользователей и объектов в каждой системе, тем дороже становится функционал – это тоже ухудшает желание пользователей что-то менять.
Например, руководитель коммерческого отдела подумает: «Мне нужно внедрить маленькую зелёную кнопочку, но для этого придётся пройти организационный, бюрократический ад, согласовать бюджет, выбить время. Потом зеленая кнопка встанет в бэклог с функционалом логистики». Маленькая зеленая кнопочка в интерфейсе становится неоправданно дорогой, на нее приходится тратить много времени, усилий и ценностного ресурса.
Нужно ли ждать у конечного пользователя рвения в изменении своих систем, когда он чувствует, что некомпетентен, что любое изменение становится слишком трудоемким и дорогим?
Какой должна быть оргструктура и роль техотдела
Согласно Domain-Driven Design, оргструктура не может расходиться с контуром. Эту мысль в конце 60-х годов сформулировал Мелвин Конвей, сказав, что «организации проектируют системы, которые копируют структуру коммуникаций в этой организации».
Статью об этом Конвей отправил в Harvard Business Review, но ее отклонили. По мнению редакции, автор не доказал, что если оргструктура и ИТ-структура расходятся – будут проблемы. Через 20 лет статью опубликовали: накопились доказательства и пришло осознание того, что если оргструктура не соответствует ИТ-контуру, все идет очень плохо.
Должно быть как-то так: у каждого отдела есть свой маленький ИТ, где есть знания, ответственность и контроль.
Но если интеграция построена таким образом, она организационно ухудшает возможность изменяться.
Например, руководитель продаж хотел бы поменять свою ИТ-систему, но как только он ее обновит, к нему прибегут другие отделы с вопросом о кросс-тестировании. Да, ты меняешь что-то у себя, но потом тебе придется думать о том, как синхронизироваться с другими отделами. И если что-то пойдет не так – виноват будет руководитель продаж, и мотивации ему это не добавляет.
То есть в парадигме компетентности у нас есть неполное знание о системе, есть ответственность, но нет контроля и полномочий. Треугольник компетентности разрушается.
Как построить гибкий IT-контур
Теоретически первый шаг к гибкости должен быть таким, чтобы каждый отдел общался только с очень понятным, стабильным промежуточным слоем, за общение с которым он и ответственен. Например, коммерческий отдел в своей системе, в своем ИТ-контуре отвечает за взаимодействие с промежуточным слоем и берет данные только из него. Тогда в этой парадигме теоретически может быть компетентность.
Это не «серебряная пуля», но необходимый шаг для того, чтобы пользователи чувствовали свою ответственность, сопричастность.
На многих выступлениях звучит вопрос: как сделать так, чтобы бизнес-пользователь видел связь между стоимостью функционала и экономическим эффектом? Это же нонсенс в нормальной оргструктуре.
Если коммерческий директор заказал кнопку за миллион, и она не принесла ему миллиона – это должно быть очевидно: запускается цикл обратной связи, человек учится. В следующий раз, когда коммерческому директору понадобится кнопка за миллион, он уже взвесит все «за» и «против» без сложных знаний.
Когда ИТ-департамент появляется и говорит: «Я вам сейчас улучшу», найдется миллион поводов объяснить, почему это улучшение плохое. Людям будет неудобно, потому что не они это выбирали.
Если ты сам выбрал «зеленую кнопку», то будут ли у тебя проблемы со вводом в эксплуатацию? Я видел много проектов, когда после внедрения продукта пользователи начинают жаловаться: кнопки не те, здесь неудобно, там не нужно. Ничего удивительного: люди не выбирали, им навязали решение сверху.
Роль технического департамента
Встает вопрос, а какая роль технического директора, технического департамента?
Выбирать решение ему нельзя, управлять разработкой – тоже. Получается, что техотдел в современной оргструктуре должен быть коучем: если мы не можем повлиять на выбор, мы можем помочь с выбором.
И тогда технический отдел становится не тем, кто занят и перегружен операционной работой, а тем, кто ходит по рынку и собирает самые лучшие решения – разработчиком стандартов.
Стандарты должны быть разумными. Если в ходе аудита исполнения стандартов выясняется, что они не исполняются, нужно принять какие-то управленческие решения по этому поводу. Грубо говоря, технический департамент – это инспекторы ГИБДД, которые помогают водителям – пользователям – снизить аварийность.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.
