Почему, как правило, возникает необходимость проведения ИТ аудита в компании? Основная причина – недовольство уровнем работы ИТ служб.

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

Почему так происходит? Может потому что хочется сделать все и сразу? Но пирог съесть целиком не получится, надо резать на части. Т.е. надо начинать с малого. С другой стороны чтобы оценить возможности привлекаемой компании, лучше им дать проявить себя на небольшом участке за небольшие деньги. И уже по этим результатам можно решать, стоит ли далее сотрудничать с этой компанией. Таким образом можно как минимум сократить риски от неуспешного аудита и проекта по улучшению ИТ систем и ИТ служб. А так же увеличить вероятность найти ту компанию, которая реально поможет. Что может быть выбрано в качестве участка для опробования возможностей привлекаемой компании? Ну скажем доступность какой-то системы. Или какой-то из основополагающих ИТ процессов. Для такой работы нет необходимости проводить глобальный аудит. Можно начать с экспресс аудита (буквально один два дня) какого-нибудь процесса, к работе которого есть претензии. И очень быстро можно проверить помогли ли рекомендации. В течении менее месяца можно получить первые результаты, получить понимание стоит ли сотрудничать и как двигаться дальше.



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

Почему возникает необходимость проведения ИТ аудита какого либо процесса? Причины могут быть разными

• Нет вообще никакого понимания о работе процесса, эффективен ли он, измеряем ли, можно ли его контролировать и управлять им.
• Процесс работает не эффективно и им недовольны пользователи, которых процесс обслуживает
• Процесс работает не эффективно и им недовольны участники процесса.
• Процесс работает не эффективно и им недоволен владелец процесса.
• Процесс работает не эффективно и им недовольно руководство компании
• Руководство хочет оценить зрелость процесса
• Руководство хочет оценить эффективность процесса
• Руководство хочет повысить зрелость и эффективность процесса

Какие цели ставит перед собой экспресс аудит ИТ процесса?

• Оценить уровень зрелости процесса
• Найти слабые места в процессе
• Выработать рекомендации по повышению уровня зрелости процесса
• Выработать рекомендации по поэтапному достижению максимального уровня зрелости

Какие работы предполагает экспресс аудит ИТ процесса?

• Изучение регламента процесса, и прочих нормативных документов связанных с процессом
• Изучение реализации процесса в системе автоматизации
• Опрос владельца и менеджера процесса
• Опрос участников процесса, оценка их зрелости
• Опрос пользователей процесса
• Определение уровня зрелости и согласование с заказчиком
• Выработка мер по повышению зрелости процесса
• Создание плана работ по повышению уровня зрелости процесса

Какие результаты получаем в результате экспресс аудита ИТ процесса?

• Согласованный уровень зрелости процесса
• План мероприятий по повышению уровня зрелости процесса
• Примерная динамика повышения уровня зрелости процесса

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


ИТ Практика предлагает услуги по проведению экспресс ИТ аудита

Любому руководителю легче работать с работниками которые имеют некий достаточный уровень знаний. Но готовых работников подобрать весьма не просто. На рынке труда их очень мало. Значит надо взять способных и обучить уже у себя. Но обучение отнимает не мало времени руководителя если он это пытается делать сам. На основную деятельность времени не останется. Или же обучение не будет эффективным. Опять же работника взяли чтобы от него уже получать отдачу, а если перед этим его надо месяц а то и два учить (и не понятно какой будет результат), то время когда начнем получать отдачу от работника отодвигается в неопределенную перспективу.

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

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

Концепция быстрого обучения позволяет дать основные теоретические знания и развить ключевые навыки в течении недели. И работник может быть уже полезным. Тесты и практические занятия помогут закрепить материал и проверить как усвоены знания и навыки. При необходимости выдаются сертификаты о прохождении курсов. Обучатся рабоник может в удобное для него время и не будет ограничен временными рамками.

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

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

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

Мы предлагаем методику быстрого обучения навыкам специалиста информационных технологий. Хотя ее можно применять и для обучения другим премудростям. Образно методика построена на принципе по которому лепят снеговика: сначала небольшой снежок, который потом все больше и больше обрастает снегом (знаниями).

Основные принципы концепции быстрого обучения базируются на законе Парето - 20% усилий дают 80% результата. Вот они:

1. Обучение 20% (или около того) процентам базовых теоретических понятий. Это понятия которые помогут понять суть изучаемой дисциплины. Обучение теоретических понятий складывается из изучения и закрепления полученных знаний тестами или опросами.

2. Получение 20% практических навыков. Это навыки которые уже позволят выполнять какую-то полезную деятельность в изучаемой дисциплине. Обучение практическим навыкам складывается из прохождения практических занятий с закреплением тестами или самостоятельными работами.

3. Практическое применение полученных теоретических знаний и практических навыков. Формирование следующего уровня нужных теоретических знаний и практических навыков.

4. Следующий виток обучения.

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

Посмотрите примеры быстрой и легкой подачи информации о процессах вот в этих статьях Легко о процессах

А вот здесь приведены курсы построенные по такому принципу Быстрое обучение

Всегда ли внедрение дорогой системы известного брэнда для автоматизации процессов управления инцидентами и проблемами – гарантия того, что все будет хорошо работать? К сожалению нет. Из моего опыта: достаточно крупный розничный банк внедряет систему Сервис Деск достаточно известную на рынке. Проект признают успешным, вендер гордо заявляет, что это одно из лучших внедрений. Но по факту количество инцидентов из года в год растет (удваивается). Т.е. основная цель процессов сопровождения – улучшение сервиса – не выполняется. Более того, процессы построены так, что отчетам из системы нельзя доверять, измеримость процессов не обеспечена. Почему так случается? Незрелый заказчик зачастую вносит в базовый процесс какие-то пожелания, которые ломаются его и делают не эффективным. Зачастую теряется сам процесс. Получаем, что любой пользователь может делать что хочет, поменять все, так как ему кажется правильным, а иногда, чтобы что-то скрыть или нарисовать ситуацию, которая ему удобна. Почему же вендер не останавливает это? Ему хочется быть хорошим («Клиенто-ориентированным»), для заказчика. И он готов в угоду этому сломать любой процесс.

Как же понять, что с процессами не все ладно?

В первую очередь надо понять какое количество инцидентов регистрируется в системе, а какое разрешается мимо системы. Если регистрируется, скажем, 20%, то понятно, что информации из системы верить нельзя. Процесс живет мимо системы. И скорее всего процесса как такового и нет. В таком случае в первую очередь надо добиваться, чтобы все инциденты стали регистрироваться в системе. До этого и говорить не о чем.

Если же инциденты регистрируются в системе процентов на 90%, то можно уже опираться на информацию из системы. На что мы должны обратить внимание? Какова динамика инцидентов по месяцам в целом и в разрезе сервисов. Если количество инцидентов держится на одном уровне или хуже того растет, то процессы сопровождения скорее всего работает не эффективно. Поскольку их цель – постоянное улучшение сервиса. Так же мы должны понимать, сокращается ли время разрешения инцидентов, что характеризует улучшение обслуживания.

Мы так же должны понимать следят или Владельцы процессов и Менеджеры процессов за показателями и метриками. Если ли у них видение или план по улучшению процессов и сервисов, которые эти процессы обслуживают. Это показатель того, ведется ли улучшения процессов и сервисов ведется целенаправленно.

Для более глубокого понимания причин необходимо планомерный анализ процесса. Скажем его аудит.

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

Состав:

Scrum состоит из Scrum-команд в которых распределены соответствующие роли, перечня мероприятий, артефактов и правил. Размер команды 7 плюс/минус 2 человека.

Артефакты методологии Scrum:

1. Product Backlog – общий журнал Требований к Продукту – список требований содержащий элементы развития продукта (User story), дефекты требующие исправления (Bug), и тому подобное.
2. Product Burndown Chart - Динамика достижения цели продукта Показывает как успешно движется создание продукта
3. Sprint Backlog – часть общего журнала Требований к Продукту, включенных в очередной Sprint для реализации.
4. Sprint Burndown Chart - Динамика достижения цели Спринта показывает насколько успешно
   реализовываются требования текущего спринта на пути достижения цели
   спринта.
5. Increment - Инкримент показывает что было сделано в процессе Спринта, т.е. доведено до готовности

Роли методологии Scrum:

1. Product owner - владелец продукта – это представитель заказчика, который отвечает за развитие продукта, ведет Backlog, выставляет приоритеты, принимает очередной Спринт.
2. Scrum master – лидер Scrum-команды отвечающий за организацию мероприятий и за повышение эффективности команды.
3. Development team – команда разработчиков производящая собственно разработку. Команда должна быть крос-функциональной и самоорганизующейся, что предполагает достаточно высокий уровень зрелости и профессионализма.

Мероприятия Scrum (элементы процесса):

1. Sprint - очередная итерация разработки длительностью в 2 - 4 недели. Длительность фиксируется в команде и далее ее стараются придерживаться. На выходе должны получить какие-то рабочие элементы продукта, которые уже можно использовать в работе. Sprint – содержит все элементы разработки: сбор и уточнение требований, разработка (кодирование), тестирование, приемка разработанного функционала и его внедрение. Как это все должно делаться не оговаривается. Команда сама должна это решить.
2. Sprint Planning - Планирование Спринта проводится до начала Спринта. В планировании участвует вся команда. В результате формируется Sprint Backlog - Журнал требований Спринта.
3. Daily Scrum – 15-минутные ежедневные совещания, цель которого определение статуса и прогресса работ над Sprint, раннее обнаружение возникших проблем, выработка решений необходимых для достижения целей Sprint-а. Участвует вся команда. Ведет Scrum master.
4. Sprint Review – подведение итогов Sprint-а. Оценивают, что было сделано, а что нет, какие трудности были и как их надо решать в будущем.
5. Sprint Retrospective – ретроспектива. На ней решают что надо улучшить в организации работ в Sprint-е.

Вот в общем-то и все. Сущностей и правил не много, но им надо строго следовать. Иначе это будет не Scrum. Более детально изучить базовые понятия Scrum можно в курсе "SCRUM В РАЗРАБОТКЕ ПО. БАЗОВЫЙ КУРС"

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

Что надо для автоматизации?

Основной элемент – Продуктовый журнал (Product Backlog). Элементы журнала должны содержать классификацию: Развитие продукта, Исправление ошибки, Задача (может еще что-то). Должен быть заголовок и развернутое описание журнала, а так же возможность вкладывать файлы. Статус элемента журнала: Запланирован, В работе, Выполнен, Отменен. А так же приоритет и ссылка на спринт.

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

Список продуктовых направлений должен содержать в качестве массива членов скрам-команды с указанием ролей.

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