12 «пробок», тормозящих IT в компании: Часть 1

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


Корпоративные IT-подразделения зачастую отличает медленная скорость работы. Вроде бы и инвестиций хватает, и кадров достаточно, и отбор по профессиональным компетенциям строгий. Почему же наряд на простейшую задачу обновления драйверов сканера выполняется месяц? Почему постоянно переносятся сроки сдачи нового веб-сайта компании? Почему во время работы пользователи часто ловят баги в только что разработанном и утвержденном приемной комиссией ПО? На основе материала с портала http://www.cio.in мы подготовили статью, отвечающую на эти и другие вопросы.




Вы уверены, что ваш IT-отдел работает достаточно быстро?

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


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


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

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

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


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


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


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

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


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

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

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


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

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

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


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


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


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

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

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


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


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


В первой части статьи мы рассмотрели шесть из двенадцати барьеров, мешающих IT-подразделениям оперативно работать и эффективно развиваться. Продолжение материала читайте здесь


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

http://www.cio.in


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

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