12 «пробок», тормозящих ИТ в компании (Часть первая)

12 «пробок», тормозящих ИТ в компании


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


Когда мы понимаем, что ИТ-отдел работает медленно? Каждый раз, когда другие бизнес-отделы вашей компании вынуждены ждать от ИТ реализации своих потребностей дольше разумных пределов. Ну например, подключить принтер – за два месяца, организовать рабочее место новому сотруднику – неделю, открыть доступ к системе документооборота – месяц… Это СЛИШКОМ долго. Современным аналогом магического заклинания «время – деньги» стал руководящий принцип «идти на голову впереди своих конкурентов». И если у вас в ИТ-отделе этот принцип не воспринимается, будьте уверены, руководство вашей компании уже потеряло терпение.


Как же придать ускорение вашему ИТ? Для начала – определите те узкие места, которые, подобно автомобильным «пробкам», тормозят эффективность вашего ИТ-отдела. В этом материале мы описываем 12 наиболее типичных «пробок». Не медлите!

«Пробка» №1: управление рабочими процессами

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


Чтобы этот затор расчистить, начните с размера: комиссия или комитет численностью больше пяти человек обычно затягивает принятие необходимых решений до критического срока. А если еще в этой комиссии нет человека, по-настоящему сведущего в ИТ, то считайте, что правильных решений в принципе не будет. И время в таких органах будет тратиться на беспредметные споры вместо совместного решения вопроса. Кроме того, комитеты собираются редко – как правило, раз в месяц или даже в квартал. О каком оперативном принятии решений здесь может идти речь? Сколько перспективных и нужных для бизнеса проектов «умерли» в ожидании принятия решения координирующим комитетом? Просто подсчитайте…


Выход – во внедрении новой культуры управления. Откажитесь от изжившей себя схемы принятия решений. Попробуйте популярный ныне эджайл (Agile), особенно подходящий для проектных команд ИТ. Разработайте грейдинговую систему, по которой присваиваются приоритеты проектам. Составьте подробную карту бизнес-процессов, исключите лишние звенья, заполните «пробелы», введите новые. Методологий много, выбор есть. И – больше прозрачности. Когда вся компания видит не только общую цель, озвученную ТОПами на ежегодном собрании, а четко различает ступеньки, ведущие к этой цели – проекты, – именно так формируется новая, основанная на ответственности за результат, корпоративная культура.

«Пробка» №2: мультизадачность

Говоря о мультизадачности сотрудников, мы представляем себе офис, заполненный гибридами Юлия Цезаря и восьмирукого Шивы. Отчего-то (несмотря на массу научных исследований, доказывающих обратное) в бизнес-среде по-прежнему широко распространено мнение, что многозадачные сотрудники (этакие «универсальные солдаты», каждый из которых и швец, и жнец, и на дуде игрец) более эффективны и менее затратны. Что же происходит на самом деле? Горькая правда состоит в том, что мозг любого человека может предельно концентрироваться на решении одной-единственной задачи. Да, в фоновом режиме он может обдумывать еще две-три, какие-то процессы происходят на подсознательном уровне (и ответ может прийти даже во сне – истории известны прецеденты))), но сосредоточиться, чтобы сделать действительно хорошо, можно только на одной задаче.


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


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


Что означает полностью укомплектованная проектная команда? Это когда для выполнения слаженной работы никому не приходится никого ждать. Сведите к минимуму число «конкурирующих» проектов, которые будут отвлекать ваших сотрудников от работы над вашим проектом. Вы очень скоро убедитесь воочию: не только каждый проект ускорится, но и все корпоративное портфолио успешно завершенных проектов будет наполняться быстрее.


Итак, объявим мультизадачности – решительное нет! Она – один из главных врагов эффективности.


12 «пробок», тормозящих ИТ в компании - третье узкое место IT

«Пробка» №3: масштабные ИТ-проекты

По сложившейся традиции компании внедряют новые технологии посредством проектов. При этом чем сложнее описание задачи, тем масштабнее проект. И чем он крупнее, тем выше риски того, что «что-то пойдет не так», тем больше вероятность отказа. Вместо того, чтобы громоздить многоуровневый проект, попробуйте работать в режиме коротких релизов, разбив выполнение задачи на несколько последовательных этапов. Это даст вам больше гибкости в разработке, тестировании и развертывании. Согласитесь, проще вносить правки в отдельные части конструкции перед сборкой, чем собрать по схеме всё, после оттестировать, а затем – разбирать собранное, чтобы исправить отдельные мелочи, упущенные на начальных этапах. Это наглядное подтверждение одной из самых надежных эвристик в ИТ-менеджменте: чем больше улучшений, тем дальше проект от завершения. Поэтому куда проще и эффективнее – двигаться путем релизов в рамках проекта. И изобретать новой терминологии для формализации этого в проектной документации не придется – назовите это модным ныне термином СКРАМ (SCRUM) и наслаждайтесь инновационным подходом к работе. Впрочем, расслабляться рано: даже переход от проекта к релизам в организации бизнеса чреват задержками: типичный период СКРАМ-спринтов составляет месяц, не считая ожиданий очередного заседания комитета по утверждению изменений. Поэтому продолжайте искать оптимальный путь непрерывной интеграции и развертывания – то есть devops. Автоматизируйте процесс тестирования, непрерывно интегрируйте любые изменения ПО и немедленно внедряйте в продуктив все мелкие изменения. Чем мельче изменения, тем меньше необходимости в их официальном утверждении. Тратить время на согласование грамматики в текстовом описании срочной задачи – непозволительная роскошь в наше время.

«Пробка» №4: ручное управление

Команды разработчиков способны самостоятельно создать полную среду разработки в облаке за считаные минуты – либо же сделать запрос на организацию рабочей среды на корпоративном «железе» силами вашего ИТ-отдела (да-да, привлекая проектный офис, системных архитекторов, бизнес-аналитиков, инфраструктурных инженеров, ИТ-безопасников и всех-всех-всех), что займет месяцы. Это перестало быть вопросом естественных ограничений, налагаемых корпоративными традициями, – в наше время это всего лишь вопрос выбора. Облачные технологии уже достигли достаточно высокого уровня. И лучший выбор между облаком и собственным сервером, как и выбор между минутами и месяцами, – вполне очевиден.


Больше автоматизации и больше возможностей для эффективной самостоятельности вашим разработчикам!

«Пробка» №5: предпочтение интерфейсам перед интеграцией

Новый функционал создает новую ценность. Однако в большинстве вычислительных центров новая функциональность рассматривается через призму минимального воздействия новых изменений в ПО на принятую в компании разветвленную (а порой и запутанную) систему кастомизированных пакетных интерфейсов вида «точка-точка».


Что советуем мы? Распутывайте этот клубок интерфейсов с помощью грамотно сконструированной системы интегрирования, – вы сразу отметите, как ускорились проектные команды, как сократилось время на тестирование и насколько быстрее происходит развертывание.


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


12 «пробок», тормозящих ИТ в компании - шестое узкое место IT

«Пробка» №6: подавление «сумеречного» ИТ

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


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


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


Читайте продолжение статьи: https://www.sim-networks.com/blog/12-bottlenecks-part-2


Оригинал статьи:

http://www.cio.in


Редактор: Алиса Кандеева

Понравилась статья? Поделитесь ею в социальных сетях!