Рынок есть рынок, хотя для ИТ-компаний сертификация по ISO 9000, я бы сказал, вынужденная мера, так как заказчики о других стандартах на проекты разработки информационных систем (далее ИС) просто ничего не знают, и всем компаниям такого профиля приходится втискиваться в «прокрустово ложе» ISO 9000.

Это большой вопрос.

Понятно, что для проектов заказчику гораздо более уместно потребовать от компании соответствие модели управления именно проектами, например стандарту по управлению проектами PM BoK.

Например, PM BoK создан как раз для управления отклонениями именно в процессе выполнения проекта.

А еще есть стандарт Tick-IT, который вообще «заточен» под ИТ-проекты и на повышение вероятности достижения запланированных в них результатов.

Но мода есть мода, и заказчик про другие стандарты, наверно, вообще ничего не знает.

ISO есть у всех, а почему у вас нет?

Так что, как там, у классика: «Цели поставлены, задачи определены – за работу, товарищи!»

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

Не слышали байку про ежиков?

Вот она прямо про такой случай:

…Жили-были мыши, и все их обижали. Как-то пошли они к мудрому филину и говорят:

– Мудрый филин, помоги советом. Все нас обижают, коты разные, совы. Что нам делать?

Филин подумал и говорит:

– А вы станьте ежиками. У ежиков иголки, их никто не обижает. Мыши обрадовались и побежали домой.

Но по дороге одна мышка сказала:

– Как же мы станем ежиками? – и все побежали обратно, чтобы задать этот вопрос мудрому филину.

Прибежав, они спросили:

– Мудрый филин, а как же мы станем ежиками? И ответил филин:

– Ребята, вы меня ерундой не грузите. Я проконсультировал вас, что вам надо делать, вот идите и делайте!

Или еще:

…Воздушным шар попал в полосу густого тумана.

На земле едва видны очертания человека.

– Вы не скажите, где я нахожусь? – крикнули с шара.

– Вы находитесь на воздушном шаре, – ответили с земли.

– Наверное, вы работаете консультантом? – прокричали с шара.

– Да, а как вы догадались?

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

Одного меня, как носителя знания требований стандарта, для работы вполне достаточно.

Готовлю и провожу презентацию для «личного состава», где честно и откровенно раскрываю все карты:

– Уважаемые коллеги!

Перед нами поставлена цель – получить сертификат на систему качества.

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

Перед нами только два пути.

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

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

– Да, вы правы, меня именно для этого и взяли на работу. Шутка.

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

По этому варианту мы, конечно, уложимся в поставленный срок – полгода.

Второй путь отличается от первого только тем, что мы с самого начала действительно выстраиваем нашу работу в соответствии с ISO 9000 и готовим реальную документацию – в этом случае врать на аудите вам уже не придется.

Но срок придется оттянуть месяца на три, не меньше!

Почему так долго, ведь документировать можно всего за два-три месяца? Здесь дело не в сроке документирования, а в том, что для честного прохождения аудита нашей системе нужно пройти так называемый цикл Деминга: «запланировал – сделал – проверил – поправил».

– Да, правильно. Его еще называют циклом Шухарта – Деминга.

– Я сейчас тоже поумничаю. На самом деле в практике управления производством его впервые упомянул еще Тейлор. Так что цикл должен по праву называться циклом Тэйлора – Шухарта – Деминга. Интересно, что сам Деминг, так много сделавший для продвижения подхода с позиций процесса, в этом цикле показал операции, а не процессы. Цикл был кратким изложением метода проб и ошибок, эффективность которого всегда была ниже всякой критики. Судя по многочисленным публикациям, этот довольно-таки древний и слабый управленческий прием воспринимается в стандарте ISO 9000 как откровение. Хотя вы правы, можно короче и точнее: «выяви недостаток и устрани его».

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

– Нет-нет! Разводить бюрократию мы не будем – любые отклонения от внутренних стандартов возможны, но только обоснованные и с документированием принимаемых решений!

Но «вернемся к нашим баранам». Вы поняли – надо, чтобы наша система поработала и прошла хотя бы одну итерацию перед ее аудитом.

Так что я целиком за второй путь!

– Правильно, Алексей, придется просить заказчика еще подождать!

Аргументирую отвлеченным примером.

Допустим, вам предлагают купить машину, а вы говорите, что возьмете, но без мотора (сейчас денег нет, и ездить пока некуда), а вот кузов вам здорово понравился и вы хотите в нем покрасоваться перед соседями. И даже прокатиться можно – под горку. А вот чтобы она сама вас возила – придется все-таки встраивать мотор и за отдельные деньги.

Невыгодно.

– Да, вы правильно слышали, что при внедрении ISO 9000 необходимо разрабатывать должностные инструкции!

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

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

А вот процессу постоянного обучения и повышения квалификации в этих обстоятельствах мы будем уделять гораздо больше внимания, чем это требует ISO 9001:2000. Для проектных услуг это просто жизненно необходимая задача – информационные системы развиваются «катастрофически» быстро!

Поэтому обучение должно стать одним из основных производственных бизнес-процессов в нашей с вами СМК.