Архив рубрики: QA

Quality Assurance
Все о качестве и процессах в ИТ

Тренинг: Решение проблем с помощью RCA. Методики и инструменты.

Недавно провел тренинг по Root Cause Analysis (RCA). Презентация: Решение проблем с помощью RCA. Методики и инструменты.

Тема RCA или по-русски, анализ корневой причины – достаточно широкое понятие.

Если обобщенно, то RCA — это подход к решению проблемы через выявление ее причин. Причем, требуется выявить основную причину — из-за которой все и началось.

rca1

Применение RCA

Как запустить RCA?

По большому счету, не существует четкого порядка. В процесс RCA пихают все что кажется приемлемым для решения конкретного класса проблем.

Для правильного RCA необходимо уметь задавать правильные вопросы и правильно обрабатывать исходную информацию. 

Хочется добавить — еще нужно правильно жить)

Дадим наиболее подходящий (субъективно, с моей точки зрения) набор шагов по осуществлению RCA:

  • Выявить и определить проблему.
  • Собрать информацию о проблеме.
  • Выявить связи между всеми возможными причинами проблемы (например, рекурсивно задавая вопрос «почему»)
  • Выяснить, какие причины следует убрать, чтобы устранить проблему
  • Определить решения, наиболее эффективные для устранения проблемы. Решения должны поддаваться вашему контролю.
  • Реализовать решения
  • Наблюдать следствия решений и повторить RCA при необходимости

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

  • Начать стоит, думаю, с метода 5W2H — чтобы собрать больше информации по ситуации
  • Далее, несомненно — метод 5Why — для простого, буквально 10-ти минутного анализа проблемы
  • Запускаем серьезную артилерию — Диаграмма рыбья кость. Возможно покажется сложным, но ты только попробуй — очень качественно сортирует проблемы и вправляет мозг
  • Также, метод блок-схем. Это очень банально — описать ситуацию/процесс блок-схемой, но мало кто делает. Зря.

Остальные методы не упоминаю, их дофига, и смысл их использовать, если не осилил даже перечисленные)

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

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

Презентация: Решение проблем с помощью RCA. Методики и инструменты.

Подождите, сейчас разрушу вашу компанию, никуда не уходите

prostiteКнига Карен Фелан, «Простите, я разрушил вашу компанию». Кто такая Карен? Консультант, основатель консалтинговой фирмы Operating Principals.

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

Итак, книжка неоднозначная, но в целом правильная и полезная. Must read.
Некоторые мысли из книги.

1. Планирование стратегии? Только в пределах разумного.

Вспомни черного лебедя Талеба. Но есть хорошие примеры — Улисс Грант, Дуайт Эйзентхауэр — «при подготовке к сражению…планы бесполезны, а вот планирование — обязательно». Таким образом, разработка стратегии и планов компании — должно стать постоянным динамическим процессом изучения текущей реальности, и корректировки. Планирование — обязательно, п.ч. без этого не узнаешь деталей, которые понадобятся для следующего шага после начала сражения.

2. Показатели — это средства, а не цели. 

kpi

Я знал это, чувствовал, но не знал как выразить:)  Моя процессная душа всегда была за метрики, но подвох чувствовался всегда!
Цели есть у всех. Наиболее продвинутые пытаются создать систему метрик, описывающих критерии достижения этой цели. Например — хочу похудеть. Тут же метрика всплывает — 12 кг за 3 мес. Что тут плохого? А то, что цель на самом деле — похудеть, не ухудшив здоровья. Чувствуете разницу? Чтобы правильно описать настоящую цель, придется выпиливать огромную систему показателей. И на кого тогда мы похожи? На водил, упертых в свои приборные панели. Но чтобы не разбиться, нужно на дорогу смотреть, и лишь иногда на панель.

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

А если не послушаетесь, то получите:
Букет ненужных последствий, полученных из-за желания следовать KPI (дать водилам автобусов метрику по прибытию на остановки вовремя, и они забудут про сервис и уважение, будут тупо ездить по времени).
Мошенничество и приписывание. И ничего ты не сделаешь с этим, п.ч. у сотрудника 8 часовой рабочий день, чтобы придумать как лучше перестать быть винтиком в твоей тупой машине, и получать максимальный профит в дырявой системе метрик. Никакая система метрик не победит сотрудников, если ты ставишь ее на первое место, а не твоих же сотрудников.
Конфликты там, где они не должны быть. П.ч. метрики одного отдела будут конфликтовать с метриками другого отдела. Например, продажники — дерутся за объем продаж. И им не нужно качество твоей работы по большому счету.

3. Управление человеческими ресурсами

biomassa

Понятие-то какое — человеческие ресурсы, биомасса ить. Лучше бы писали — работа с людьми, человечней все-таки.
Понятие эффективности людей, завсегда приятно измерить. Таким образом, получаем тему, связанную с предыдущим топиком — с метриками.
Не нужно замерять эффективность сотрудников (процесс аттестации). По определению, процесс аттестации не может быть справедливым, а значит, он опустошает, дает ложную оценку, заставляет делать не то что нужно на самом деле, тратит энергию в ж-пу.
Если кто-то хочет построить действительно справедливую оценку эффективности сотрудников, поразмыслите над этим:

  • любой из нас считает себя «выше среднего». Ну и как ты будешь обрабатывать эту ситуацию? Низкопроизводительный сотрудник обидится. И кстати, обидится и высокопроизводительный, когда ты поставишь ему 4.3 вместо 5 из 5.
  • эффективность — субъективное понятие. Никакой SMART не поможет, см тему метрик
  • формулирование целей вначале года\квартала — лишает гибкости в середине периода. Значит тут нужны подпорки в виде change mgmt process.
  • цели будут неравнозначными в разных отделах, да и в пределах одного раздела — тоже!
  • огромный объем работы нужно сделать сотрудникам, чтобы пройти все шаги системы аттестации. Помню возглас из зала, где объявляли про введение этой системы — а работать нам когда?!
  • фаворитизм, эффект ореола (когда прошлые успехи\неуспехи влияют на оценку сейчас), дискриминация по возрасту\внешнему виду бла бла..те еще темы

Возможные выходы:
— ЗП выше среднего по рынку, простейшая привязка ЗП к прибылям (это все есть у Пинка)
— взаимодействие и обратная связь менеджера и сотрудника. А не тратить время на заполнение бланков и отчетов.
— позволять сотруднику выбирать себе цели, в рамках возможного

Лирическое отступление о славянском факторе. Некоторые прожженные российские менеджеры скажут, что эти подходы не сработают для славянского менталитета, с его совком и халявой в крови. Действительно, у нас долгая и не очень веселая история. Однако, какого хр.на нам нужно ориентироваться на прошлое, а не брать передовой опыт и учитывая прошлое, адаптировать, находить новые, свои подходы?
Знаю, что в великой ит компании из трех букв, где я работал, меня пошлют на те же 3 буквы. Но даже там, я уверен, можно выстроить прогрессивную, человеко-ориентированную среду. Ну разве что придется уволить 60% менежмента, и потратить лет 20.

4. Остальное

Как стать хорошим менеджером? Да просто, быть нормальным, адекватным человеком:) Интерес к окружающим, общение, гибкость. Поддерживать хорошие отношения, это ведь не бином Ньютона (вообще то сомневаюсь, бином попроще иногда). Хорошую ссылку дала на Кислород гугла.

Модели менеджмента не имеют реальной ценности, а беседы с сотрудниками — имеют. Единственный способ чему то научиться — работать с людьми, а не читать про это.

Принцип Питера — в иерархической структуре, работники поднимаются до уровня своей некомпетентности. И это не лучший вариант для нас, не так ли? Но как я понял, мир еще не придумал, как эффективно справляться с этим эффектом.

Худшее, что может сделать клиент — нанять кого-то (меня), кто будет думать вместо него. Это намек всем нам, консультантам — делаем так, чтобы клиент сам начал думать, а не оставляем его с отчетом и планом действий:-)

И прежде, чем дать совет клиенту, подумай о последствиях:)

Итак, книга к обязательному прочтению и применению, для каждого консалтера и просто манагера.

Оценка:
Сложность чтения: легко
Полезность: высокая
Оценка: 9/10 (не 10, п.ч. в конце книги совсем уж очевидности описаны)

Внедрение процессов и практик

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

Если у меня спрашивают о полноценном внедрении процесса, то я выставляю только один критерий — внедрение должно осуществляться как проект. Ну и как вы понимаете, в проект можно много чего напихать:)

Ниже — идеализированная схема внедрения процесса:
2015-06-16_proc_impl_full

По центру — основные активности, справа дана временная шкала, чтобы можно было сравнить со следующим вариантом. Звездами выделены ключевые вещи.
Итак, что получаем:

  • Если у нас проект, значит нужна рабочая группа, нужен план и прочие аттрибуты проекта. В плане должны быть прописаны KPI процесса, также ключевые цели, которые должны быть достигнуты в процессе внедрения процесса.
    Лет 5 назад я бы сказал, что план — очень важен. Сейчас так не думаю:) План — это заготовка, база, которая должна постоянно корректироваться.
  • Задачи из плана должны полностью замениться бэклогом задач — по результатам совещаний рабочей группы.
  • Рабочая группа — важнейший момент (все самое важное выделено красной звездой). С момента формирования группы и до закрытия проекта, рабочая группа регулярно встречается, и корректирует ход внедрения процесса. Дело в том, что каким бы смарт разработчик процесса не был, он не предскажет и половины проблем, возникающих в процессе внедрения. Для этого нам и нужны постоянные корректировки.
  • Разрабатывается документация (регламент процесса).
  • По результатам работы группы, и созданному ей бэклогу задач — выполняются мероприятия. Например, поиск и внедрение подходящего инструмента. Согласование соприкасающихся процессов и т.п. Тут могут быть целые под-проекты, и просажена куча усилий.
  • Промежуточные аудиты — в основном построены на прописанных KPI (которые кстати тоже сабжект для корректировок при необходимости).
  • Тренинги для целевой аудитории. Обычно вначале выбирается группа хомячков, все обкатывается на них. Потом тренинг проводится на всей целевой группе. В эту группу не обязательно входит вся компания, думаю это понятно.
    Хорошо, если вам нравится проводить тренинги. Ведь это выступление перед людьми:)
  • Экзамен. Лично мое убеждение — без экзамена сотрудник а) несерьезно относится б) при всем желании фигово запоминает и не проникается темой.
    Единственный минус экзаменов — большой геморрой с внедрением системы экзаменации. Это реально большая отдельная тема.
  • Закрытие проекта — с отчетом, с анализом ошибок.

Это была идеальная картинка (думаю многие смогут еще ее доидеалить, чтобы в космос полететь).

А в жизни в 95% случаях происходит все вот так:
2015-06-16_proc_impl_basic

Т.е., на основе анализа разрабатывается некий документ, который спускается на компанию. Далее, в зависимости от пожеланий бизнеса, процесс может докручиваться, возможно даже с использованием аудитов. Но частенько процесс на бумаге становится неактуальным через 15 минут после публикации, и дальше начинается параллельная жизнь бумажного и реального тигров.
Но обратите внимание на график работ — на такое вот минимальное внедрение потребуется в 3 раза меньше времени.

Какие выводы? Я понимаю, что идеальную схему внедрения нам доведется исполнить в жизни раз 6. Разве что вы работаете в NASA или атомной энергетике.
Поэтому рекомендую отталкиваться от базового варианта, с привнесением компонентов из полного варианта, по ситуации.

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

Удачи всем нам с внедрением процессов!

PS в статье я делаю допущения по поводу процессов — не углубляюсь в область управления процессом, упоминаю только про KPI процесса, не даю определения и прочее.

Об интеграции замолвите слово или Company integration

Источник фото http://svetlechekblog.ru/post232412418/

Источник фото http://svetlechekblog.ru/post232412418/

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

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

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

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

Поэтому, как проинтегрируем эти процессы, так и поплывем дальше.

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

  • Initial stage — постановку целей для интеграции, Due Diligence и собственно, заключение сделки
  • Implementation stage — корректировка планов, выполнение интеграции.
2015-05-18_integration

Общий план по интеграции компаний

 Initial stage

Эта стадия больше относится к выяснению коммерческих интересов сторон, уточнению юридических аспектов. Также, на этом этапе, еще перед подписанием документов, должно начаться планирование.

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

Implementation stage

Планы дорабатываются, составляются детальные списки задач для каждой области (streams).

Можно выделить ключевые под-этапы implementation stage:

  • 1-й день после официального объявления об интеграции
    Это важный день — встречают по одежке. Хорошо подготовленное вводное письмо на всех сотрудников, подготовительные действия для последующих шагов.
  • Первые 100 дней интеграции
    Базовые вещи должны быть сделаны — интеграция финансовых потоков, HR, ICT и тд. После 100 дней компания должна быть в состоянии принимать и исполнять проекты материнской компании.
  • Средне-срочные цели (mid-term), например 4-6 мес. для компании в 100-150чел.
    Цели, поставленные бизнесом должны быть выполнены.
  • Долгосрочные цели (long-term), 1-1.5 лет
    Полная интеграция завершена. Включая интеграцию культур компаний, а это дело непростое.

Классически, весь объем работ разделяют на следующие streams:

  • Operation management
  • Finance mgmt.
  • ICT
  • HR
  • Marketing & Sales
  • Production Processes
  • etc.

По каждому stream необходимо назначить лидера и определить рабочую группу. Это может выглядеть так:

Stream name Company-Acquirer представители CompanyName представители Описание stream
Управление компанией   Стратегия, оперативное планирований, постановка целей и контроль выполнения, определение правил работы компании
Оперативное управление Тактика работы над проектами, процессы взаимодействия, процессы разработки и тестирования, документация, поставка и гарантии, модели проектов и контрактов. Модели разработки, градация сотрудников, карьерный и профессиональный рост. Используемые для разработки и контроля средства, системы и тулы.
Оперативное управление   Успешная работа — time reporting, рабочие процессы и тд
Поддержка бизнеса Визы\командировки, обработка входящей\выходящей документации, заказ канцтоваров и др
Финансы   Финансовый анализ, бухучет, инвойсирование, контракты с заказчиками CompanyName и др заказчиками.
HR     Трудовые отношения с сотрудниками, рекрутинг, соц пакет и бонусные программы, прогноз роста з/п и анализ рынка труда
Коммуникации Коммуникация с прессой, информирование сотрудников, организация мероприятий
Marketing & Sales   Продажи, предложения Заказчику, формирование цены.
Брендинг компании, сайт компании
ICT и инфраструктура   Закупка HW, SW, набор тулов, единая сеть, общие сервисы (email, colaboration and communication)
корпоративные порталы, единые системы учета рабочего времени, репортинг, заявки, управленческий учет и т.д.
Process & tools Интеграция процессов, создание портала для CompanyName
etc.  

Дальше, каждый stream должен проработать план, т.е. буквально — что, когда и кем должно быть сделано. В разработке подобных планов пригодятся чеклисты.  Вот пример чеклиста по ICT — ICT integration checklist_example

 

Некоторые из success factors

  • Интеграция — это проект
    Трактуйте интеграцию как полноценный проект, а не одну-две задачи. Проект предполагает проектный подход. Здесь и план проекта, и отчетность, и другие аттрибуты полноценного проекта. Особенно важно управление рисками. По этой теме пишут отдельные книжки.
  • Коммуникация, коммуникация
    Без полноценного информирования на разных этапах target audience — все может загнуться. Собственно, больше всего страдают сотрудники купленной компании. При недостатке информации они чувствуют себя купленным барахлом (может так оно и есть в глазах руководства?)
  • Оптимальное расположение сотрудников
    Хорошо было бы расположить сотрудников из одних и тех же отделов поблизости друг от друга, чтобы был постоянный обмен и убирались барьеры. Как пример — перелоцировать в одно место сотрудников отдела продаж.
  • Ставим точку
    Не забудьте завершить проект интеграции. Вовремя поставленная точка — сэкономит время\деньги\моральный дух. Не нужно перфекционировать, пора покупать следующую компанию:)

Удачных интеграций!

О создании культуры компании

2015_05_culture-is-built-not-bought-fiВначале, что такое культура компании?

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

Например, культура компании в области ИБ, это когда:

  • при входе коллеги без бейджа в периметр, другой коллега искренне удивляется — «ты кто такой?».  Хотя он за соседним столом сидит, и квас вместе пьют.
  • за кофе ПМы подкалывают друг друга за разглашение информации о клиенте,  «мужик, держи изоленту» (см ниже картинку)

Вырисовалась эффективная схема по построению так называемой культуры ИБ:

  1. Прорабатывается тема, например — список сведений, составляющих коммерческую тайну компании
  2. В регулярных новостях компании (например в еженедельных письмах всем сотрудникам) делается краткий анонс об этом. Завуалировано, с интригой, типа скоро будет что-то прикольное
  3. Не тормозя, публикуется документ (в нашем случае перечень коммерческой тайны), и сопроводительное письмо к нему.
  4. В этом письме — краткий пересказ документа, без фанатизма, чтобы человек смог прочитать за 30 сек, и (! бинго) — в конце письма комикс по теме!
2015_05_isolenta

Комикс к публикации документа «Сведения, составляющие коммерческую тайну». Создано by Varvara Petrova:)

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

Некоторые шутки превращаются в истории, которые старожилы рассказывают новичкам. Не это ли культура компании?

2015-05_company-culture-cartoon

 

О создании внутренних порталов (Intranet Portal)

intra process0 Проблема и решение

Создание внутреннего  портала  компании, корпоративного  портала , intranet — с этим вопросом сталкивается рано или поздно любая компания, особенно «айтишная».

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

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

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

1 Создание  портала 

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

Дело в том, что внутренний  портал  — это отражение компании во всех ее уникальных аспектах. Даже внутренняя (негласная) культура компании отразится на ее  портале. Конечно же, есть некие общие компоненты, например — база документов, новостной блок, корпоративная wiki и тд. Однако их компоновка, способ представления, интеграция — делается иногда совершенно удивительными способами.

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

1.1 Создание концепции

В принципе, базовую концепцию будущего  портала  создать легко. Нужно всего лишь:

  • узнать текущее состояние компании, ее проблемы
  • узнать пожелания ключевых пользователей будущей системы
  • на основе собственного анализа, и высказываний людей (их проблемы и их предложения) — скомпилировать список основных модулей  портала  и их интеграцию

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

Это очевидный подход, но есть проблема — люди не знают что они хотят на самом деле. Поэтому концепция, составленная только лишь на мнении опрошенных людей будет в лучшем случае удовлетворительной, т.е. посредственной.

Для того, чтобы сделать действительно классную концепцию, ей должен заниматься визионер, человек — видящий будущее, стратегически предугадывая критически важный функционал для пользователей. Вспомните Стива Джобса.

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

1.2 Создание концепции 2

Вы знаете, как создаются большинство инновационных продуктов сегодня? Их воруют из других идей. Человек видит одну идею, вторую, десятую. А потом они вдруг компилятся у него в голове, решая проблему, над которой он бьется.

«Воровство» при создании концепции — это нормально. Понятно, что по сути это не совсем воровство.

Я рекомендую просмотреть текущие дизайны intranet от Якоба Нильсена, см Intranet Design Annual: 2007 (Free Report). Якоб на одном из форумов выложил также в свободный доступ версию за 2010 год, поэтому передаю вам на скачку и этот отчет. А может вы соберетесь с финансами и купите последнюю версию за текущий год?

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

Больше про правильный процесс воровства идей можно почитать в хорошей книге Остина Клеона «Кради как художник.10 уроков творческого самовыражения».

1.3 Реализация концепции

Из всего многообразия функционала, нужно выбрать самые важные features, обозвать все это например «Release 1″, и сконцентрироваться только на функционале, вошедшем в Release 1. Ни больше, ни меньше.

Далее в ход вступает проектный менеджмент. Если вы выберете agile подходы, то детальную спецификацию можно не делать. Лично мне больше нравятся смешанные подходы, классическа + agile. Поэтому рекомендую на первых порах сделать достаточно подробную спецификацию, включая кликабельный mockup — т.е. модель  портала . Благо инструментария на сегодня хватает. Этот mockup очень сильно поможет с продвижением идей  портала  для менджмента  и ключевых людей на проекте. А дальше, со спецификацией в руках и головой на плечах — все дело техники.

Удачи с реализацией!

Внедрение ISO 9001. Часть 2 — как это делается.

внедрение1Продолжаем, см предыдущую часть тут.

Итак, руководство компании решило внедрять ISO 9001. А вас, собственно, назначили ответственным за внедрение СМК и ее последующее сертифицирование на ISO 9001. С чего начинать?

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

Шаг 1. Сформировать управляющую команду компании

Что это? Группа топ-менеджеров компании, непосредственно влияющая на развитие компании. Казалось бы, очевидная вешь — в любой компании есть руководители отделов, они  ведь и являются этой самой «управляющей командой»?

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

Поэтому управляющую команду компании нужно именно сформировать. Это означает:

  • Официально определить ее, и назвать, к примеру «Управляющая команда»:) Ненавязчиво объявить всем сотрудникам что есть команда менеджеров. А самим менеджерам — объяснить зачем это и какие обязанности у них по этому поводу.
  •  После запуска — поддерживать моментум. Проще всего — через регулярные совещания, скажем раз в 2 недели. 

Управляющая Команда отражает базовый принцип ISO 9001 — вовлеченность руководства. Это будет основным инструментом для реализации всех остальных принципов и подходов.

На первых встречах Управляющей Команды (УК) можно обсуждать ход проекта по внедрению ISO 9001. В дальнейшем — эти совещания будут посвящены бизнесу, а вопросы СМК будут лишь малой частью агенды.

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

Команда сформирована, что дальше?

Шаг 2. Определить Миссию и Стратегию и компании.

Согласитесь, без Управляющей Команды (УК) невозможно выработать миссию компании?

Вероятней всего, у вас не получится с ходу определить Миссию и Стратегию. Это дело требует времени, иногда месяцы и годы. Но тут важно запустить процесс. Можно посвятить одно совещание брэйнштормингу, на другом — обсудить обновленные идеи, также мысли рядовых сотрудников (руководители должны привлечь их на промежуточных этапах). Зафиксируйте полученные результаты, попробуйте пожить ими несколько месяцев. Потом вернитесь и обновите. Это процесс, не статика.

По поводу выработки Миссии и Стратегии компании - существует множество подходов. Со своей стороны рекомендую посмотреть принципы, которые использует Стивен Кови в своей книге "8й навык".

Может показаться, что всякие миссии и стратегии не важны для небольшой компании. Возможно и так. Но сам процесс определения миссии и стратегии сплотит УК, научит работать вместе — а это очень важно для дела.

Получив Миссию компании, и Стратегию компании на ближайшие годы — можно переходить к текущим Планам и Целям компании. Тем более, что ISO 9001 требует, чтобы руководство компании определило цели компании в области качества (5.4.1). Мы же будем определять не только цели в области качества, но и вообще, в любой области деятельности компании.

Шаг 3. Определить Планы и Цели компании

Как правило, на начальном этапе Цели компании будут повторять основные моменты проектного плана по внедрению ISO 9001. Например, там 100% будет цель — «Внедрить и сертифицировать СМК компании в соответствии с ISO 9001».

Рекомендую разбить Цели на секции, характерные для вашей компании. Разбивать можно по основным процессам, либо по подразделениям компании. Скорее всего в Целях вашей компании будут секции: на уровне компании, разработка ПО, маркетинг, управление инфраструктурой и т.д.  Пример Целей компании можно посмотреть на странице Ресурсов — Цели компании 2014_пример

Источником для Целей будут:

  • проектный план по внедрению ISO 9001
  • результаты первоначального аудита компании (его делает эксперт — опрашивает ключевых людей всех отделов, составляет общую картину, презентует УК)
  • самый важный источник — планы каждого подразделения, которые предоставляют их руководители

Важный момент, вы должны убедиться, что все цели — SMART, т.е. конкретные, измеряемые, достижимые, релевантные и с дедлайнами. На деле выстроить такие цели сложно, но жизненно важно.

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

Внедрение ISO 9001. Часть 1 — кому это может быть полезно.

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

1) Каким компаниям и когда необходим ISO 9001
Большим ИТ компаниям ISO 9001 малополезен, и даже вреден, п.ч. большие компании имеют уже сложившиеся за годы бизнес-процессы, как правило, перекрывающие требования стандарта. Все-таки ISO 9001 — базовый стандарт, требующий лишь основы.
Другое дело — небольшие ИТ компании, скажем в 50-100 человек, с временем существования 1-5 лет. Для таких компаний создание живой Системы Менеджмента Качества (СМК) на основе ISO 9001 — большое благо.
Конечно же, данный подход несколько упрощен. Нужно учитывать множество факторов, как-то; зрелость менеджмента, специфика бизнеса, готовность персонала и т.д. Однако для 90% ИТ компаний, попадающих под описанные критерии, внедрение ISO 9001 принесет пользу.
Какую пользу?

2) Польза ИСО 9001
Весь инет исписан «пользами» ISO 9001. В основном пишут банальности, типа увеличение конкурентоспособности или увеличение прибыли. С моей т.зр. польза следующая:

  • мобилизация менеджмента компании, выработка умения работать одной командой;
  • улучшение коммуникации между отделами, способность решать общие проблемы, выходящие за рамки одной команды\отдела;
  • документирование базовых процессов, создание шаблонов и процедур — серьезно помогает при вводе новых сотрудников в дело, при реализации сложных проектов;
  • структуризация целей компании — от самого верхнего уровня, до уровня проектов;
  • отслеживание эффективности достижения целей, метрики и KPI — возможность для принятия более релевантных решений;
  • ах да, заказчикам нравится что у вашей компании есть красивая бумажка «Сертификат ISO 9001» 

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

Как внедрять ИСО 9001 в небольшой ИТ компании? Об этом в следующем посте.

SECR 2012

Пишу хоть и запоздало, отклик на конференцию «Разработка ПО 2012».
Программа со всеми ссылками на доклады и даже на видео — http://www.secr.ru/lang/ru-ru/program/agenda

Конференция большая, навороченная.
Перед посещением таких мероприятий я решил сформулировать ожидания, получился список областей, в которых хотелось бы продвинуться:
— новые идеи
— знакомства с интересными\важными людьми
— проф развитие, выбор новых направлений
— темы для будущих выступлений (что интересно аудитории)?
— измерение и управление качеством (чего?) продукта

Вот с такими радужными мыслями прибыл я в Москву.
Читать далее

Семинар Increasing Business Effectiveness of IT Companies through Risk Management and Certification Standard

Посетил семинар “Повышение эффективности ИТ компаний с помощью риск менеджмента и сертификации”, 10&11 июля, организатор — Европейский Банк Реконструкции и Развития.

Ниже — краткая сводка.
Читать далее