Откажитесь от количественных оценок работы. (Уильям Эдвардс Деминг)

Практические вопросы Управления качеством или Пособие по подготовке к разработке и внедрению Системы Менеждмента Качества

В. В. Ильин

1. От автора

"Знающие не говорят,

говорящие не знают."

Лао цзы

Почему.

Многие предприятия в России сейчас пытаются внедрить системы менеджмента качества ( СМК)  и сертифицировать их на соответствие требованиям стандартов ISO 9000 {1}.

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

Но основная причина внедрения стандартов ISO 9000 на российских предприятиях всеже - либо внешнее давление, либо желание следовать моде. Случаи, когда работа начата в результате осознанного и всесторонне продуманного решения, к сожалению редки.

Но независимо от побудительного мотива, если решение о внедрении принято, необходимо разобраться с многочисленными вопросами именно практического внедрения СМК.

Концептуальной основой международного стандарта на СМК -ISO 9000 является то, что организация создает, обеспечивает и улучшает качество продукции при помощи сети процессов, которые должны подвергаться анализу и постоянному улучшению. Для обеспечения правильного управления процессами, организации взаимодействия между процессами в сети, ИСО 9000 предполагает, что у каждого процесса должен быть "владелец" - лицо, несущее ответственность за данный процесс. Этот "владелец" должен обеспечивать однозначное понимание всеми участниками процесса их ответственности и полномочий, должен организовывать взаимодействие при решении проблем, если процесс охватывает несколько функциональных подразделений предприятия.

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

Для кого.

Эта книга написана не для специалистов - они уже давно все тонкости этой темы хорошо знают.

Эта книга написана для Вас - решивших разрабатывать и внедрять СМК в своей Компании.

Поэтому и позиционируется, как пособие по подготовке ( или самоподготовке Компании) к разработке и внедрению сиcтемы управления качеством.

Зачем.

Внедряя автоматизированные системы управления производством , описывая и глубоко вникая при этом в бизнес-процессы клиента, стремясь оптимизировать их, мы-консультанты, по существу, всегда ведем  заказчика к последующему созданию СМК.

Но , занимаясь вопросами Бизнес-инжиниринга в Компаниях различного профиля и проблемами разработки и внедрения систем менеджмента качества , приходится сталкиваться с большими проблемами  ясного толкования  основ всех этих процессов , связанными не только с процессами разработки и внедрения СМК, но и с,  что особенно важно для практики, ее дальнейшим  совершенствованием .

Сейчас на  тему  СМК  существует уже огромное множество работ самого разного масштаба. Все они, как правило , носят  методологический и теоретический характер и предназначены, по большей части, для специалистов - системных и бизнес-аналитиков. В них жонглирование формулировками требований стандарта ISO 9000 часто затуманивает суть того,  а что необходимо реально делать,  чтобы наладить процесс управления качеством.

Как

Опыт работы консультанта однозначно подсказывает, что не только при обучении персонала  и подготовке данных для построения процесса управления качеством  (см. п. 11  и 16 ),  но и на  всех этапах разработки СМК ( см. п.  14  ) необходимо использовать метод наглядности -схемы,  рисунки и диаграммы.

В этой книге мне и хотелось , как раз,  и добиться Вашего понимания именно сути самого процесса управления качеством ( УК) .

Поэтому рисунков здесь будет  много - это позволило сделать размер книги достаточно компактным и тем самым заметно повысить плотность информации . Здесь будет  высказано  мнение об УК в целом ( см. п.  2 и 13  ) и рассказано о мифах и реальности ( см. п.  3 и 12  ) в практике его внедрения.

Чего Вы здесь не найдете

Здесь специально  не будет сказано ни слова о содержании самих требований стандарта ISO 9000 - ведь этот стандарт,  только одна из многих возможных моделей построения СМК !

Да и пересказывать и тем более трактовать его нет смысла - это в той,  или иной степени уже сделано во всех других книгах об СМК !

Здесь не будет и примеров необходимой для прохождения сертификации документации.

Вы ее прекрасно напишете сами прочитав всю ее целиком.

2. СМК -мифы и реальность

"Где ничего не положено -нечего и взять"

Евангелие от Матфея .

Построение СМК - это теперь достаточно модное у нас дело.

Вот с модностью и связан первый миф об СМК.

Миф первый : " СМК  шагает к нам с запада, как передовой опыт эффективного капиталистического производства".

На самом деле это совсем не так - это, как раз наш , советский, уже  хорошо забытый опыт.

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

Однако, мало, кто знает, что в начале  80 - тых годов,  руководящие посты в ISO занимали наши чиновники из Госстандарта,  и при разработке  стандарта  на СМК (ISO 9000) его разработчики во многом опирались ( и особенно  в части  документирования процессов и принятия решений, разработки метрик процессов, управление изменениями) на корпоративные стандарты управления качеством  в нашей оборонке.

И  реальность в том, что модель системы качества ISO 9000 выросло из недр  именно Российского военно-промышленного комплекса. Именно СМК позволила нам  и запустить спутник,  и сковать ракетный меч, и выстроить ядерный щит.

Мы у себя в России опять вырастили дерево, а плоды с него снимать, как обычно, начали на Западе.

Но вернемся к СМК.

По  поводу внедрения СМК уже написано очень много хорошего и правильного текста.

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

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

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

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

Миф второй : СМК можно  просто "внедрить" .

В жизни внедрение СМК идет по двум сценариям.

Сценарий первый и, к сожалению, достаточно типовой.

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

Но после получения долгожданного сертификата , половина документации СМК  "вдруг" становится абсолютно бесполезной , а вторая половина имеет крайне низкую эффективность.

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

Его цель - получение сертификата и демонстрация его Заказчику.

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

Сценарий второй ,  правильный.

СМК  выращивается в компании, выращивается  стремлением повысить эффективность и качество своей работы. Почвой ( в которой производителем уже заложены все питательные микроэлементы для этого плода ), на которой можно успешно вырастить СМК,  является внедрение уже апробированных систем управления предприятием различной степени  сложности - так называемых Бизнес - приложений класса ERP ( Enterprise Resource Planning - по простому система планирования ресурсов предприятия).

Методология внедрения ERP-систем, как раз и включает анализ производственной деятельности и оценку ключевых бизнес-процессов (БП) предприятия в целом.

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

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

Но такие проекты в настоящее время являются скорее исключением.

Обычно ограничиваются внедрением только частью ERP -системы и, как правило,  даже всего двумя модулями: финансы и логистика. Именно в  этих процессах всем хочется навести порядок. И совсем, к сожалению, нет понимания того, что только полный порядок во всех Бизнес-процессах, и в управлении качеством в том числе,  даст заметный результат для Компании .

Воспользуемся отвлеченным примером.

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

Правда, такое отторжение ко всей ERP - системе в целом у нас в стране легко объяснимо .

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

Ну, и кому это понравится ?

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

Поэтому наши консультанты сформировали собственный принцип работы над проектами по созданию корпоративных информационных систем ( КИС)  - наша Компания занимается не столько внедрением продукта, сколько стремится повысить эффективность бизнеса компании-заказчика путем внедрения ERP-методологии.

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

Другими словами не "клиента под модель, а модель под клиента"!

Удачным примером, к сожалению пока единственным , является  наш  проект внедрения системы управления BAAN IV  на  Нижегородском химико-фармацевтическом заводе (ОАО "Нижфарм). Введение в промышленную эксплуатацию модуля "Управление качеством" стало логическим продолжением стратегической линии ОАО "Нижфарм" на развитие и наращивание функциональности информационной системы предприятия.

"То, о чем так долго говорили" на рынке информационных технологий в области внедрения ERP-систем, наконец стало реальностью: впервые в России предприятие получило полнофункциональную интегрированную систему управления предприятием, охватывающую всю цепочку движения товарно-материальных ценностей в производственном процессе: от закупки материалов, управления складским хозяйством, управления производством до реализации готовой продукции с отражением всех финансово-хозяйственных операций и ведением денежных расчетов и системой управления качеством! Что и позволило этому предприятию в  январе 2003 г. успешно пройти сертификационный аудит  его СМК  на соответствие требованиям ISO 9001:2000.

Но вернемся к мифам.

Миф третий: "Мы возьмем на работу специалиста и он нам все сделает сам".

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

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

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

Ведь оценивается, не как учитель вас учил, а как вы поняли предмет.

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

Представьте себе, что поставлена задача покрасить забор ( внедрить и эффективно использовать СМК). Менеджер по качеству может красить его только с одной ( внешней) стороны (карты процессов (process mapping), элементы  ISO серии 9000, метод разработки стратегии и политики, цикл Деминга (PDCA cycle), оценочная система по Нортону-Каплану (Balanced scorecards)), с другой,  внутренней, (выполнение всех утвержденных регламентов и процедур СМК ) его может  красить только  персонал компании под ответственным руководством его топ-менеджмента. Поэтому, если персонал компании не вовлечен в эту деятельность ( а часто так и бывает, поскольку Руководство всегда занято глобальными проблемами и только формально рулит процессом построения СМК), забор так и останется покрашенным только с наружной стороны. И если при сертификационном аудите исхитрится не показать "внутреннюю часть забора" ( рассказываем аудитору все, как надо, а сами работаем, как раньше ), то и сертификат получить можно.

Но сама жизнь подсказала  удачный вариант совмещения лидерства Руководства компании  и руководства внедрением СМК - это введение должности Директора ( или Зам. директора ) по Качеству. В тех компаниях, где есть такая должность, понимают всю важность работ по СМК - только магический авторитет должности "Директора" позволяет правильно наладить "покраску забора с внутренней стороны".

Миф четвертый и самый часто обсуждаемый: "Компания получила сертификат, но качество работ или услуг не улучшилось. Так какая польза от этой СМК?".

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

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

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

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

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

Миф пятый и очень коварный: "СМК  - это самостоятельная  система управления, необходимая только для прохождения внешнего аудита и получения сертификата".

Это прямой и очевидный результат типового сценария. Здесь все так и есть - СМК сама по себе, а управление компанией  само по себе.
Давайте вспомним, из чего состоит СМК - это и планирование, и контроль, и анализ показателей, и регулярные проверки на протяжении всего жизненного цикла услуги или продукции.

Если добавим  мотивацию и управление финансами - вот и готовая система управления компанией. Она хорошо документирована, прозрачна  и понимаема  персоналом.

Ну, и зачем изобретать велосипед?

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

Наверно,  дело здесь в консерватизме. Руководство засасывает текучка, оно бесконечно решает проблемы производства,  а СМК? - ну, пусть будет еще и СМК.

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

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

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

Это именно тот человек,  который и может сделать СМК  необходимой для  компании .

Кстати о мотивации . О ней всегда говорят , либо вскользь , либо предпочитают не упоминать вовсе.

И понятно почему - и так постоянные внутренние проверки и регулярный сбор, расчет и анализ данных отнимает много рабочего времени,  а тут еще за это плати ! Какому руководителю такое понравится?

А это вовсе не второстепенный фактор - ведь построить СМК можно и путем политического ( командирского)  решения Руководства , а вот  поддерживать и развивать можно только на основе заинтересованности самого персонала - см . Рис.1 .

Рис. 1.

Здесь все зависит от того, что Вы хотите получить в результате. Хотите галочку в Плане внутренних проверок , то о мотивации можно и не вспоминать. Хотите действительно улучшений ,  тогда надо серьезно думать. Давайте еще раз посмотрим на Рис. 1 - там все просто : "Сколько пива -столько песен".

И , кстати ,  о хотении. Здесь опять все тесно связано - типовой сценарий внедрения СМК,  как раз, и не предусматривает  мотивацию работ по качеству.

Но эта печальная картина приводит только к одному выводу , что Руководство не является потребителем СМК - как в старом анекдоте: купил билет, а не поехал :

Миф шестой," версионный": "Версия СМК 2000 года  - это те же 20 элементов версии 1994 года плюс еще два : схемы БП и  наличие измерений".

Нет , это существенно другая  версия, а не просто плюс еще два элемента.

Это внедрение существенно отличной от предыдущей версии философии управления: "Управлять можно только тем, что можно измерить ".

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

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

И  реальность в том, что эти "два плюса" потребуют, как минимум, полгода кропотливой работы по перестройке бизнеса и анализу его эффективности (Balanced scorecards)!

Так, что, господа Руководители, дорога ваша  опять лежит в  наш  ERP-House!

Здесь необходимо  поговорить и о другом аспекте новой версии - о том ,  что теперь (  в версии ISO 9001:2000) ,  обязательными являются только шесть документированных процедур - смотри Рис.2.

В прежней версии  , как правило , разрабатывали , как минимум , 20 процедур -по одной на каждый из 20 элементов СМК.  

По поводу обязательных - понятно : они СМК - образующие , т.е. формируют документированный цикл Деминга  ( Plan-Do-Check-Action).

А вот ,  что еще  надо в первую очередь  добавить к ним ?

Здесь нам придется ответить на вопрос - а для чего ,  в конечном счете,  создается СМК ? Самый короткий ответ  - для того ,  чтобы увеличить вероятность достижения запланированных результатов.

Ведь сам цикл Деминга - это просто необходимый инструментарий для достижения этих самых запланированных результатов - см. Рис. 2 .

Рис.2

Значит ,  сначала нам нужно понять ,  а  "каких результатов"  нужно достигнуть!

Вот и получается , что самой важной из дополнительных в СМК  будет процедура : "Анализ договора".

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

Чего достигать  поняли, цикл Деминга  запустили, результатов в конкретной работе по договору достигли .

А как будем повышать вероятность этого достижения в дальнейшем ?

Только с помощью второй по важности дополнительной процедуры: " Анализ эффективности СМК ".

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

3. Особенности национальной сертификации по стандарту ISO 9000

"Не зная броду, не суйся в воду!"

Народная мудрость

                                                                  или

"Зачем нужно то, что еще не нужно?"

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

1. Я утверждаю, что если позвонить в 100 Российских организаций через, скажем,  полгода после получения ими сертификата ISO 9000 на их СМК,  и поинтересоваться, ну , например, в отделе продаж ( сбыта ), или секретариате, или в службе технической поддержки,  о наличии СМК, то  в 90% случаев Вас спросят: " А что это такое ?"

2. Я утверждаю, что "бутафорскую" ( это как раз там, где Вы услышите этот вопрос )  СМК сертифицировать у нас в России гораздо проще ( я здесь имею ввиду количество обнаруженных при сертификационной экспертизе отклонений от стандарта ),  чем уже реально работающую.

3. Я утверждаю, что  в такой ситуации есть и доля вины  наших российских органов по сертификации.

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

А теперь готов прокомментировать  эти утверждения подробно.

Не секрет, что когда консультант ( у наших органов по сертификации всегда "под рукой" своя консалтинговая фирма ) приходит в Компанию, он первым делом задает вопрос: "Вам только сертификат нужен, или Вы действительно хотите внедрить СМК?". Как говориться - без комментарий (см .Утверждение №3). То есть Руководству сразу предлагают выбор между СМК "бутафорской" ( только сертификат ) и реальной. Понятно,  что создавать и внедрять реально работающую СМК значительно сложнее, чем просто подготовить необходимую документацию.

И это  известные органы!

А органы с меньшей репутацией более циничны - вот объявление ( слово в слово) из  Интернет:

" Мы предлагаем Вам  получить сертификат соответствия по международным стандартам серии ISO-9000  в реальные сроки и по приемлемой цене"

   Вот так, как на базаре кило яблок купить.

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

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

А в "бутафорской" СМК  несоответствия устраняются легко - ":лишь перо заскрипит:"(см .Утверждение №2).  

И Руководство идет по пути наименьшего сопротивления (см.Утверждение №1), тем более, что есть еще ряд очень существенных причин для такой ситуации - см. Рис 3.

Рис 3.

На самом деле, конечно , ситуация не такая уж одназначно-упрощенная,  как я обрисовал,  но,  как модель процесса размножения "бутафорских" СМК,  вполне подходит.

А одной из  причин  этого процесса размножения,  как раз и заключается в сути Утверждения №2.

Поэтому остановимся на этом утверждении подробно.

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

И для того, чтобы Вас туда пустили, Вам надо в своем костюме устранить несоответствия - "немного переделать" - вместо пуговиц вшить молнии (чтобы быстрее застегивать было),  отрезать карманы ( чтоб не принесли чего лишнего, не соответствующего), на рукава и брючины резинки поставить (чтоб не пачкать за столом и в туалете ) и т.д.

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

А если  у Вас пока еще  нет такого любимого костюмчика,  то  Вам просто предложат для этого вечера  костюм спортивного типа купить ( а он еще и значительно дешевле любимого Вам обойдеться ) - и в нем на вечер без всяких замечаний пустят (см.Утверждение №2) .

Конечно, я слишком сузил проблему, но смысл в том, что когда Компания выращивает свою СМК ( пока без целей ее сертифицировать ) она  "шьет костюмчик по своей фигуре" .

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

Это в значительной степени зависит еще и от политики сертификационного органа.

Действительно, представим себе ,что СМК - это некая "коробка передач" для машины. Если взглянуть на разобранную новую коробку передач ( провести ее "аудит" ), то, что броситься в глаза в первую очередь ?- заусенцы на шестеренках  и даже ,иногда,  остатки  стружки.

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

Здесь я хочу, как говорит наш Президент ( сейчас модно цитировать Путина), отделить мух от котлет.

СМК -это система управления качеством продукции (любимый костюмчик),  а ISO 9000 -это одна из множества возможных моделей СМК (спортивный костюм ). Поэтому,  когда я говорю про СМК, я имею в виду систему качества,  которая адаптирована к конкретному производству. Она может быть очень эффективной и функциональной ,  но, при этом, иметь много отклонений от модели ISO 9000 .

Требования ISO 9000, конечно, чтобы Вам ни говорили консультанты любого уровня о его "рамочности" и универсальности,  заточены  под производство в его прямом ( "заводском") смысле.

Например, для  ИТ -Компаний сертификация по ISO 9000 мера,  я бы сказал, вынужденная, так как Заказчики  о других стандартах на  проекты разработки Информационных систем (далее ИС)  ( например: SPICE , Tick-IT) просто ничего не знают и всем Компаниям такого  профиля приходиться втискиваться в "прокрустово ложе" ISO 9000. А нужна ли в действительности   модель ISO 9000, например, проектно-ориентированным ИТ- Компаниям? Это большой вопрос -

См.  ниже п  7.

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

Ведь эта модель управления проектами как раз и создана для  управления отклонениями именно в процессе выполнения проекта и для повышения вероятности достижения запланированных в нем результатов - см. Рис 4 .

Рис 4

Или, например, зачем такой Компании проводить при закупках оценку качества приобретаемым для нужд проекта ( инсталляции ИС ) серверам Hewlett-Packard  или маршрутизаторам Cisco Systems ( это все очень важно, но при  закупках сырья для производства, например, самолетов или обуви , а HP он и в Африке HP) ?

Но модель ISO 9000 приобрела очень большую популярность ( именно в связи с его понятным и простым "заводским" характером)  и все большее число Заказчиков ИС - систем хотят видеть его логотип на "знаменах" своего поставщика, не вникая в суть дела (у всех есть ISO,  а почему у вас нет).

Ведь сертификация СМК - это акция,   направленная вовне Компании - она призвана продемонстрировать ее способность  обеспечивать и непрерывно улучшать качество. Поэтому при анализе соответствия работающей СМК ("любимый костюмчик" ) требованиям ISO 9000 ( спортивный костюм ) все зависит от искусства интерпретации этих требований на реалии Компании. Когда такого "искусства интерпретации" у консультантов, как правило,  нет, им проще всех рядить в безликие   "спортивные костюмы" (см.Утверждение №3) .

Это все происходит потому, что миллионы компаний и сотни надзорных органов интерпретируют стандарты ISO 9000, как образец построения СМК.

А кто сказал, что именно эта модель так уж необходима для каждой Компании?

Вот Билл Гейтс не имеет сертификата ISO 9000 в своей Microsoft, и ничего ( даже захватил 90% рынка пользовательского ПО )!

Давайте разберемся .

В стандартах ISO СМК рассматриваются, как набор настраиваемых и постоянно улучшаемых элементов,  функционирование которых  обеспечивает процесс управления качеством.

Но сама-то модель статична! Она не учитывает:

• эволюцию продукции и технологии ее производства;

• индивидуального развития конкретного производителя;

• развитие технологической базы ;

• социально-экономических  факторов;

• конкурентоспособности и рыночных  факторов .

А именно это  определяет конечную эффективность  СМК, функционирующей в реальной производственно-экономической среде.

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

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

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

Вот почему во многих случаях высококачественная продукция становится в определенный момент просто невыгодной.

И в этом случае СМК становится просто нежизнеспособной.

А мировой опыт показывает, что успех достигают именно те предприятия, которые балансируют производственные, коммерческие и финансовые цели, т.е. работают на повышение своего потенциала ( я предпочитаю использовать свой термин -Качество Потенциала Компании - далее КПК). Уровень КПК ( а это не что иное, как уровень развития его Бизнес-Процессов или на западный манер -КПК  -Business Process Improvement) характеризует жизнеспособность предприятия, обеспечивая шанс получения прибыли в будущем-см. Рис. 5.

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

Уровень КПК  "Соответствие фактическим требованиям Потребителей" определяется не только соответствием стандарту предприятия, но и удовлетворением эксплуатационных требований (потребностей потребителя). С этим уровнем КПК  соотносятся такие  уровни как "Контроль" и "Оптимизация". Вот здесь как раз место СМК по модели ISO 9000 - она обеспечивает уровень "Контроль" и механизм перехода на уровень "Оптимизация"-см. Рис. 5 .

Рис. 5

Для предприятия, соответствующего КПК уровню "Контроль" высокое качество продукции будет соответствовать и высокой цене на нее. Предприятие с КПК уровнем "Оптимизация" характеризуется приемлемым соотношением цены и качества продукции.

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

Вот здесь,  при переходе от 3 уровня к четвертому и далее ,  СМК по  модели ISO 9000 еже ничем Компании помочь не сможет.

Последний уровень качества - "Предвосхищение потребностей Потребителей". Качество продукции данного уровня направлено для удовлетворения будущего спроса. Этот уровень  характерен для предприятий КПК уровня "Мировой класс".

Поэтому только  внедрение ИТ-системы, как правило ERP-класса, можно рассматривать как обеспечение процесса достижения 5 уровня -т. е. значительного улучшения  Бизнес-процессов  организации и управления предприятием-см. Рис. 6.

Рис. 6

Для успешного внедрения ERP-системы необходимо учитывать, что именно люди, работающие на предприятии, могут использовать или не использовать методик КПК , заложенных в основу ERP-системы. Для того, чтобы люди  прониклись данными методиками, как раз и необходимы ( требуемые ISO 9000) и Политика и Цели в области качества, и осознание всеми сотрудниками своего вклада в их достижение, и программы улучшения производства. Обеспечение регулярного использования методик в рамках ERP-системы осуществляется как раз методами СМК (методы обеспечения качества, методы стимулирования качества, методы контроля результатов по качеству).

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

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

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

С использованием ERP-системы решается проблема естественной интеграции комплексного управления качеством в управление бизнесом. ERP-система и СМК являются взаимно дополняющими инструментами непрерывного улучшения бизнес-процессов (КПК ).

Вся наша многолетняя  практическая работа по внедрению корпоративных ИС  подтверждает вывод о том, что ERP-системы и СМК взаимодополняют друг друга на пути достижения цели непрерывного улучшения бизнес-процессов  -см. Рис. 5.

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

Интуитивно это понимают все Руководители, но Заказчики требуют от них сертификат ISO 9000 уже сейчас,  и вместо того,  чтобы начинать "шить любимый костюмчик" по фигуре (внедрять ERP -систему управления производством и строить на ее основе свою СМК) , они покупает "спортивную " униформу ( сертификат на "бутафорскую" СМК) - см .Утверждение №1.

А к бутафории в государственном масштабе наши руководители уже привыкли - помните "Знак качества" на откровенном браке при социализме?

Всем известна поговорка, что "в России две беды : дураки и дороги".

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

Старшее поколение хорошо помнит социалистическое соревнование, "знамя которого мы несли все выше и выше". Поэтому, когда у нас услышали про ISO 9000 , то  быстро организовался "серый" рынок, обеспечивающий всех желающих сертификатами "в приемлемые сроки и по разумной цене ".

Здесь  еще надо понимать,  что  такой подход самих российских предприятий - еще и  следствие того, что в нашей стране не было и до сих пор еще нет реальной проблемы качества - см. Рис 3.

По сути это даже самая основная причина - нет потребности в реальной СМК,  а только  для Заказчика - сойдет и бутафорская.

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

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

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

А чего стоит "обогащение"  мировой  науки новым экономическим процессом - "откатингом"? Ведь у нас , что ни Субподрядчик,  то команда Заказчика для легализации "отката".

И наконец, еще один важный момент - кто в Вашей Компании будет рулить СМК?

Если это будет просто менеджер по качеству ( типа начальник ОТК ), то это прямой путь к превращению реальной СМК в бутафорскую - см. Рис 7.

Рис 7

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

Вот о чем надо думать нашим руководителям,  а не о "покупке" Сертификата ISO 9000!

Кстати, именно по этому  на Западе далеко не все предприятия сертифицированы по ISO 9000 (я уже упоминал Microsoft). Многим это и не нужно. Ведь сам сертификат ни о чем не говорит, кроме как о том, что предприятие проверили.

И вовсе не является гарантией качества. ISO 9000 - это необходимое, но далеко недостаточное условие обеспечения  качества.

Он (сертификат )  не утверждает, что производство правильно организовано .

Для подтверждения этого существует другой механизм - инспекционный аудит.

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

За вынесенный вердикт инспектирующая сторона будет отвечать и финансово, и юридически.

Только после этого можно уже говорить о качестве.

Поэтому на Западе органы по сертификации СМК находятся в постоянном напряжении.

Они не могут позволить себе такую халтуру.

А наши -  пока  могут.

4. Роль Бизнес-моделирования в построении СМК

"Зри в корень"

К. Прутков.

1. Концепция моделирования БП

Бизнес-моделирование (БМд )- это системный подход описания целей, структуры, механизмов и регламентов деятельности компании и их связей между собой, направленных на достижение стратегических целей и целей в области качества в том числе {1, 9}.

На Рис. 8 в стилизованном виде показан системный подход к организации  эффективной СМК.

СМК в этой концепции состоит  из двух основных модулей :

• интегрированной Бизнес-модели (Интегрированной БМ -ИБМ) - "пирамида" структуры БП не дает ухудшить качество работ ,  

• цикла управления процессами -цикл Деминга - "диск" Plan -Do-Check-Action обеспечивает качество работ и его постоянное улучшение,

и одного вспомогательного - системы электронного документооборота.

Рис. 8

Задача создания ИБМ решается путем  бизнес-моделирования  {2} деятельности компании.

Задачу реализации цикла Деминга решает цикл управления ИБМ.

Цикл управления БМд  включает в себя :

• анализ внешней и внутренней среды компании,

• планирование и разработку решений,

• реализацию, учет, контроль,

• анализ и корректировку возникающих отклонений.

Внедрение в компании элементов управления БМд  позволяет:

1. Ориентировать операционную деятельность компании на стратегические цели развития бизнеса и цели в области качества в том числе;

2. Осуществлять контроль реализации корпоративной стратегии через систему сбалансированных показателей деятельности ( BSC);

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

4. Осуществлять поддержку, регулярный мониторинг и управление изменениями ИБМ компании;

5. Поддерживать все стандарты и регламенты компании в актуальном состоянии;

6. Оптимизировать деятельность по управлению развитием и изменениями.

Роль и место БМд  в процессе выполнения проекта разработки и внедрения  СМК показана на Рис. 9.

Рис. 9

На схеме  ниже приведен базовый план построения  архитектуры ИБМ компании и практические способы ее создания- см. Рис. 10

Рис. 10

Самым оптимальным , как показывает наша  практика,  в БМд  при разработке ИБМ является смешанный подход- это, когда моделирование идет навстречу : и сверху вниз, и снизу вверх.

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

ИБМ Компании, в соответствии с методологией {2}, представляет собой  документированное описание:

• стратегичеких целей и задач,

• дерево продуктов и услуг,

• дерево функций,

• организационной структуры,

• Бизнес-процессов ( БП) и процедур ,

• структуры информационных потоков и документов,

• структуры данных и  регламентов,

• структуры ресурсов и прикладных систем,

• взаимосвязи всех указанных объектов и структур.

Сумма всех Бизнес-моделей (БМ ), необходимых для описания всего Бизнеса Компании , и представляет собой ИБМ , пример Архитектуры которой представлен на Рис. 11.

Рис. 11

Такая СМК может быть очень эффективной ( высокая степень вероятности достижения всех запланированных результатов  ) , но, при этом, иметь много ( и  существенных ) отклонений именно от популярной модели ISO 9000 {1}.

Например, такая СМК  вообще не будет иметь "Руководства по качеству" ( а это самое "страшное" отклонение от стандарта ISO 9000!) - его с гораздо большим успехом  заменяет электронный репозитарий моделей всех БП компании!!

И уже давным  давно  существует ПО ARIS  (Architecture of Integrated Information System -программная среда для описания и моделирования БП ) {2},  где в электронной базе  репозитария  БП предусмотрена вся необходимая их детализация и ресурсное окружение  вплоть до уровня рабочего места.

Права доступа пользователя гарантируют персоналу санкционированный доступ к нужным частям базы данных ARIS и каждый сотрудник видит на своем компьютере только те  реальные процессы и функции, в которых он участвует ( вместо пожелтевших от времени "Рабочих инструкций" над рабочим столом), а руководители имеют всю информацию по данным мониторинга всех ключевых показателей деятельности ( КПД )!

В такой СМК отпадает необходимость и в составлении ( а подчас "вымучивании") должностных инструкций,  которые все время нужно будет актуализировать в процессе управления изменениями при постоянном совершенствовании всех БП - а здесь все действия персонала "по умолчанию" уже расписаны в процедурах того же репозитария БП и автоматически актуализируются при изменениях в регламентах БП!

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

И корректирующие и предупреждающие действия в такой СМК уже встроены в механизм управления БП  ( см. Рис. 8 ) в виде специальных процедур управления отклонениями от нормального хода БП , и ,соответственно,  не нуждаются в дополнительных бумажных  процедурах (и   это тоже существенное отклонение от требуемого стандартом ISO 9000 {1} необходимого набора документированных процедур).

И не нужна тут никакая отдельная "Политика в области качества", которую "надо доводить до персонала" и планы достижения целей и т.п. - все это опосредовано уже включено в ИБМ в виде стратегий , целей и критических факторов успеха {1}!

Остановимся теперь еще на одной очень важной задаче при разработке СК.

В  рамках решения задачи управления персоналом, который  реализует стратегии и задачи СМК , существуют только две проблемы:

• как сформировать эффективный кадровый потенциал Компании,

• как сделать труд этих "кадров" действительно эффективным.

Причины неудовлетворенности руководителей работой своих подчиненных являются следствием неправильного решения  одной из этих задач. Однако, прежде чем  менять сотрудников надо задать себе  простой вопрос: "А знают ли они точно, что от них хотят?".

В традиционном подходе к описанию организации через  "Должностные инструкции" ("вымученные" отделом кадров ) предпринимается попытка выявления функций "целого" через функции "частей". Поэтому созданные таким образом документы всегда во многом расходятся с действительностью и реальные требования руководителей к деятельности своих сотрудников остаются не выявленными .

В процессе БМд сначала последовательно описываются стратегии, цели и функции компании, и затем они распределяются по исполнительным звеньям вплоть до конкретных сотрудников. Это и есть  правильная постановка процесса управления персоналом, которая тоже обеспечивается БМд -см. Рис. 12.

Рис. 12.

Построенная по рассмотренной концепции СМК, никогда не станет формальной ( то есть бутафорской), как это достаточно часто случается с просто бумажно-документированными СМК, построенными по формату модели {1}.

Она будет четко работать, как швейцарские часы, поскольку "заведенный" в ней  анализ результатов мониторинга КПД  будет постоянно подстраивать ее на оптимальный режим функционирования!

2. А что дает БМ?

Для этого проанализируем традиционные ( особенно "традиционные" для российского менталитета)  проблемы {9}, которые встречаются практически в любой Компании:

• Отсутствие структурированной системы получения данных от подразделений.

• Несогласованность действий между службами. 

• Дублирование работ.

• Отсутствие отлаженной системы документооборота между отделами.

А причина только одна  - большое количество обособленных операций соединяется только через управленческий аппарат, что неизбежно влечет большие расходы на взаимодействие между подразделениями (в денежном, временном и т.д. выражениях) -см. Рис 13 .

Рис 13

Все наверно знают  пресловутый  Закон "80\20".

Это ,  когда 80% работы выполняют 20% сотрудников, или, когда  20% населения обладают 80% его богатств.

Так вот , согласно статистике в типичной  бизнес-системе 20%  времени занимает выполнение операции, а 80% времени уходит на передачу информации: на  рабочем месте человек выполнил свою функцию, передал руководителю информацию о выполненной работе, далее информация попадает к секретарю, лежит на столе у секретаря 1 - 2 дня, после ложится на стол руководителя. И далее в обратном порядке. Получается значительная  задержка,  а может  , даже, искажение информации ( прошло много времени и на данный момент показатели могут резко измениться ).

Если сомневаетесь, то можете прохронометрировать процесс движения того или иного документа в Вашей Компании.

И кто способен проделать всю эту кропотливую работу по моделированию?

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

И именно таких специалистов особенно недостает сегодня в российских компаниях.

Мне ближе термин системный аналитик ( СА ), так, как Компания рассматривается, прежде всего, как единая Бизнес -система .
СА  способен рассуждать "от общего к частному", а не только наоборот, что характерно для узкого функционального специалиста.

3. Так, что же должен уметь и знать СА?

Ответ в стилизованном виде дает Рис. 14

Рис. 14

В вашей Компании есть такие специалисты?

Если нет,  то  Вам нужно их взять на работу или вырастить обучением из числа продвинутого ИТ -персонала.

Это необходимое условие, но не достаточное  - придется все-таки обращаться к консультантам ( Кого выбрать - Вы узнаете ниже) .

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

управления .  

При этом звучат , как правило вызывающие чувство Вашей собственной неполноценности,  англоязычные термины - BPR ,ERP,TQM . И каждый   предлагает  только своё решение ( опять звучат англоязычные названия систем : Oracle, BAAN,  SAP,  Axapta и т.д. ) , не объясняя, чем оно отличается от других, и в каких случаях его лучше применять.
Вообще , руководитель не обязан сам знать всех тонкостей каждой ИТ -системы- последнее  должно лежать на плечах, как раз,  внутренних системных аналитиков .

4. И так, что же делать?

Из выше изложенного Вы поняли, что описание БП является сложной и трудоемкой задачей , требующей хорошей профессиональной подготовки  и нуждается в конкретной методологической и инструментальной платформе {2}. Но для  Вас формулировка такой задачи является еще  новой и  своими силами Вы пока не в состоянии разработать свою бизнес-процессную модель .

Где же выход?

Да там же, где и вход!

Разумно воспользоваться идеей бенчмаркинга ( это новомодное слово означает просто изучение лучшего чужого опыта  и  внедрение его у себя) .

А для выполнения  работы привлечь  консультантов и объединить их в одну группу со своими внутренними СА ( из числа продвинутого персонала  или взятых специально на работу для дальнейшей поддержки БМ ) . В совместно образованной группе моделирования  рекомендуется обязательно предусмотреть роль администратора  бизнес-моделирования (АБМ). Основная и очень необходимая для построения целостной БМ,  его обязанность -   контроль ее целостности и непротиворечивости с позиций взаимных стыковок описаний отдельных БП!.

И ранних стадиях создания бизнес-модели функцию АБМ должен выполнять как раз   внешний консультант. Но ему необходим дублер из команды Заказчика, чтобы перенять опыт и полностью принять базу полученных моделей для дальнейшего управления изменениями.

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

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

5.  Кого выбрать?

Первое.

При выборе консультантов  существенное значение имеет наличие у них  готовых отраслевых моделей ( вот для чего они полезны в первую очередь - чтобы не изобретать велосипед своими силами):

• это свидетельствует об уровне их профессионализма в вашей области.

• наличие модели-заготовки позволяет значительно сократить время на описание рутинных  БП, которые, каким бы уникальным Вы свое предприятие не считали, всегда составляют порядка 80% ( поверьте практикующему консультанту) .

Например, наиболее типовыми БП всегда являются: логистика, бюджетирование,  закупки, выбор Поставщиков, продажи и т. п.

Второе .

Это умение консультанта увидеть пресловутые "20% моделей , которые описывают 80% деятельности "- вот для чего они полезны во вторую ( хотя, как посмотреть -может это, как раз, и в первую?) очередь - чтобы   "велосипед" не оказался  "мерседесом" .

И это, поверьте практику , сэкономит уйму времени (и Ваших средств) -см. Рис. 15.

Рис. 15

PS :

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

Пользуйтесь услугами тех, кто имеет прослеживаемый опыт моделирования именно в Вашей отрасли!

5. Определяем   показатели  БП

Глобальная цель любой науки состоит в том,

чтобы свести самое удивительное к обычному

Э. Квейд

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

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

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

Рис . 16

На Рис. 17 приведены конкретные примеры определения показателей условного БП "Отчетность".

Рис . 17

Еще одним примером возможных конкретных показателей  является перечень показателей проектно-ориентированной ИТ -Компании , расмотренный ниже в п. 7.

6. Роль маркетинга в СМК

"Я всегда стремлюсь не туда,

где шайба находится сейчас,

а туда, где она,

скорей всего, окажется".

Уэйна Гретцки

Важнейшей -же новацией новой версии международного стандарта ISO 9000:2000  стало требование именно измерения удовлетворенности потребителей.

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

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

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

Итак, маркетинг - это, по большому счету, ориентация предприятия на рынок, умение улавливать его тенденции и использовать их, предлагать на рынок именно то, в чем есть потребность и именно так, чтобы заинтересовать потребителя. Либо же, если потребности еще нет, помогает эту потребность сформировать. Если же представить маркетинг образно и кратко, то это "ключ к сердцу" клиентов (т.е. к их потребностям) -см. его место в процессном ландшафте Компании - Рис. 18.

Рис. 18. Процессный ландшафт современной Компании .

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

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

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

Чтобы более полно представить значение маркетинга в управлении производством, необходимо снова обратиться к международным стандартам. В системе определения качества продукции, отвечающей требованиям международных стандартов ISO  серий 9000 и 9004 и охватывающей все стадии "жизненного цикла" продукции (в ИСО 9004 он называется "петля качества"), именно маркетинг играет ведущую роль.

Это, как бы Замок, который соединяет в непрерывный процесс весь жизненный цикл (ЖЦ ) производства.

В соответствии с требованиями этих международных стандартов "жизненный цикл" продукции состоит из  этапов,  показанных на Рис. 19

Рис. 19. Петля качества или ЖЦ продукции в представлении стандарта ISO 9000.

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

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

Вообще не стоит начинать проектирование и разработку продукции, не изучив требований к ней потребителя- см. Рис18 .

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

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

А цели предприятия достигаются именно через оценку и удовлетворение требований потребителей ( см.  Рис.18).

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

7. Особенности  внедрения СМК в ИТ-Компаниях

"Сложностью необходимо не

восхищаться, а избегать ее"

Джек Траут.

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

Рассмотрим сначала самые важные особенности ИТ-Компаний.

1. Особенности ИТ бизнеса

Проектно-ориентированная компания - это компания, осуществляющая свою деятельность преимущественно в проектной форме. А это значит что каждый проект уникален и ни о каком конвейере нет речи .

Выбор такой формы существования  предполагает получение доходов только за счет создания для клиентов уникальных продуктов, как правило это заказное программное обеспечение (ПО ), или/и   разработка и внедрение информационных систем ( ИС ) различной сложности . Уникальность накладывает особый отпечаток и на все стороны деятельности предприятия - от стратегии на рынке до операционного уровня ее Бизнес - процессов ( БП ).

Модели описания БП,  где  Компания описывается в терминах функциональной деятельности (выделение по предмету деятельности) для ИТ -услуг не удобна. Потому, что  при декомпозиции таких моделей на уровень подразделений, БП на нижнем уровне описывают деятельность, распределенную по различным функциональным подразделениям и специалистам, что нарушает главный принцип реинжиниринга - "один процесс - одно подразделение - один бюджет - один владелец процесса".

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

Степень успешности работы проектно-ориентированной компании, естественно,  должна  измеряться с помощью системы ключевых показателей деятельности (КПД). И проектная форма деятельности здесь тоже проявляет свою специфику и в номенклатуре КПД, и в их структуре, и в способах получения их значений.

БП в проектно-ориентированной компании и осуществляются в соответствии с принятыми в этой компании  стандартами управления проектами. Напомним, что по общепризнанной методологии PMI  (Project Management Institute) -РМВоК 2000, процессная модель проекта включает несколько стандартных стадий (инициализация, планирование, выполнение, контроль, завершение), каждая из которых предполагает выполнение определенных функций, связанных с управлением временными и стоимостными параметрами проекта, с управлением рисками, проблемами, контрактами, качеством и т. д.

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

В Табл. 1 приведены возможные метрики проектной деятельности для последующего расчета  КПД.

Табл. 1

Проектная цель	Процессы	Метрики
Проект должен удовлетворять поставленным целям	Управление требованиями	Степень покрытия  тестовыми сценариями
	Управление изменениями	Количество запросов на изменения Степень изменений требований Длительность реализации запросов на изменения
	Тестирование	Количество тест-раундов Количество ошибок в каждом Общее количество ошибок
	Управление качеством	Количество аудитов проекта Количество выявленных замечаний и несоответствий
Проект должен быть завершен  в установленные сроки и в рамках бюджета	Оценка	Размер продукта Затраты Размер проектной команды
	Планирование	Количество ключевых задач Количество версий Плана Число изменений в проектной команде
	Выполнение	Количество задержек на критическом пути Процент задач выполненных в срок Процент  увеличения проектной команды Процент  увеличения бюджета Процент  решенных проблем Процент  увеличения количества тест-раундов
	Управление рисками	Число возможных рисков Процент сбывшихся рисков Процент  рисков для которых были проведены действия по их минимизации
Удовлетворенность заказчика	Качество процессов	Оценка качества проекта заказчиком Количество выявленных замечаний и несоответствий в проекте Процент устраненных замечаний и несоответствий в проекте
	Качество ИТ-продукта	Плотность ошибок Плотность оставшихся ошибок

Главной особенностью БП проектно-ориентированной ИТ-компании является их стандартная структура процессов выполнения проекта ( этапы проекта ) и стандартные ограничения (срок, себестоимость, персонал). Именно эти стандартные ограничения по времени и стоимости реализации проектов и по качеству результатов и могут быть использованы для построения интегрального (обобщенного) показателя, характеризующего БП проектно-ориентированной компании через оценку возникающих отклонений - см. Рис. 20.

Рис. 20.

И еще очень важная особенность ИТ -Компаний.

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

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

А теперь перейдем, собственно, к обсуждению возможных моделей СМК для

ИТ отрасли.

2. Модели СМК для ИТ

Когда я говорю про СМК, я имею в виду систему качества,  которая адаптирована к выполнению определенных проектов -см. выше Рис. 2.

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

И, как уже упоминалось,   например, такая СМК может вообще не иметь "Руководства по качеству" ( а это существенное отклонение!) - его с большим успехом может заменить репозитарий моделей всех БП компании- с выше про использование средств моделирования БП - Рис. 21.

Рис. 21 Структура методологии ARIS

Соответствующие права доступа пользователя и привилегии гарантируют ему санкционированный доступ к нужным частям базы данных ARIS и каждый сотрудник видит на своем компьютере только те  процессы и функции, в которых он участвует, а руководители имеют всю информацию по данным мониторинга всех метрик и самих КПД!

Поэтому для  ИТ -Компаний сертификация по ISO 9000 мера,  как уже упоминалось, вынужденная, так как Заказчики  о других стандартах на  проекты разработки ПО и внедрения  ИС , например, SPICE (ISO/IEC TR 15504-СММ, поэтому у нас более известная под абревиатурой СММ) , Tick-IT ( само название этого стандарта Великобритании говорит о его предметной области  ) и  т.д. - см. выше Рис. 4, просто ничего не знают и всем ИТ-Компаниям, как я уже писал,  приходиться втискиваться в "прокрустово ложе" ISO 9000.

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

Качество выполнения ИТ-проектов {8}  складывается из :

• определения требований  Потребителей к ИС или ПО ;

• отображения требований на функциональность ИС или ПО;

•  разработки и внедрения ИС или ПО с характеристиками, обеспечивающими соответствие установленным к ним  требований  Потребителя;

• поддержания характеристик, заложенных при разработке ИС или ПО и при их внедрении в компании Потребителя;

• технической поддержки внедренной ИС или ПО в течение их срока жизни с целью сохранения заложенных в них характеристик.

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

А именно управлению несоответствующей продукцией стандарт ISO 9000 уделяет особое внимание - он и  заточен под то, чтобы Заказчик получал продукт только установленного качества. И для заводов и фабрик это в самый раз!

Понятно,  что  для ИТ -проектов гораздо более уместно Заказчику потребовать от компании соответствие модели управления именно проектами - например, PM BoK 2000 или, более строгой, - SPICE.

PM BoK  как раз и создана для  управления отклонениями именно в процессе выполнения проекта ( а SPICE  и Tick-IT вообще заточены под ИТ-проекты) и для повышения вероятности достижения запланированных в нем результатов - см.выше  Рис 4 .

Рассмотрим, например, необходимость должностных инструкций персонала.

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

А вот процессу постоянного обучения и повышения квалификации в ИТ -компаниях в этих обстоятельствах надо уделять гораздо больше внимания, чем это требует ISO 9000: для ИТ-услуг это просто жизненно необходимая задача - ИТ-системы развиваются "катастрофически" быстро!

Поэтому  процесс обучения просто должен стать одним из основных производственных Бизнес-процессов для ИТ-Компании!

Вспомним комментарии к выше обсужденному  Рис 5 ( уровни КПК ) .

И для того чтобы добиться этого "мирового класса" ИТ- компании необходимо разрбатывать СМК уже совсем по другой модели, :." и мы знаем эту модель" - CMM - см. Рис. 22 . Уровни организации КПК по  модели CMM как раз полностью соответствуют необходимым уровням КПК!

Рис. 22

Кстати, именно по этому  на Западе далеко не все ИТ-Компании сертифицированы именно по ISO 9000 (я уже упоминал Microsoft, хотя здесь это уже не к месту , поскольку CMM у нее тоже нет). Многим это и не нужно. Для них гораздо важней вместо ISO 9000 иметь хотя бы третий или , лучше  , четвертый уровень CMM.

А если отечественная ИТ-компания, мобилизовавшись и затратив большие ресурсы, получит даже 4 уровень CMM, то на какого нашего отечественного Заказчика  это произведет хоть какое-то впечатление?

Ни на какого .

А вот ISO 9000 - :."это мы знаем":!

Теперь рассмотрим реализацию процесса управления качеством в ИТ -проектах.

3. Управления качеством в ИТ -проектах

Основной ключевой особенностью сложных ИТ - проектов является неконтрактируемое их качество. На предконтрактной стадии невозможно заранее описать в полном объеме требования к создаваемой системе или работе.

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

И все это в "ходе игры".

Это означает, что полное определение всех требований к проекту в начале его практически невозможно. Кроме того, необходимо учитывать, что в большинстве случаев цели ИТ-проекта носят качественный характер и сами по себе не могут служить основой для определения объема работ .

Кроме того, проектный бизнес имеет еще следующие общепризнанные особенности:

• интеллектуалоемкий характер предметной области большинства проектов;

• сильная зависимость успеха проектов от  поведения заказчика;

• повышенные риски нарушения сроков и бюджета, прекращения либо приостановки проекта;

• повышенные требования к качеству, имеющие конструктивный, т. е. объективно проверяемый характер;

• высокая степень индивидуализации "под клиента" и важное значение организации "плотной" работы с ним;

• быстрое моральное старение их результатов;

• высокая вероятность появления новых, ранее не выполнявшихся работ, для которых методология, технология и система управления создаются "на лету";

• высокие требования к квалификации менеджеров и исполнителей, их высокая стоимость;

• критическая важность корпоративной офисной системы, поддерживающей и бизнес , и коммуникации, и базу знаний;

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

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

Пример модели обеспечения качества ИТ -проекта уже был показан  выше на Рис. 20

Для каждого конкретного проекта в соответствии с ISO 9001 и PM BoK {1,6} сравнительно нетрудно разработать логичный комплекс мер по обеспечению качества -этот комплекс может быть оформлен, как План обеспечения  качества (QA-План ) -см. шаблон QA -плана для ИТ-проектов на Рис .23 . QA-план, как правило, является составной частью План- графика всего проекта , но может выделятся для больших проектов и как самостоятельный план ( подпроект).

Рис .23 План ( шаблон) обеспечения  качества ( QA-План )  для ИТ-проектов

Выполнение QA -плана  и процедур управления качеством   обычно приводит к удорожанию проекта на 10-15%. И для больших и серьезных проектов это абсолютно оправданно- это как раз пример необходимого предупреждающего действия ( я бы даже назвал "мегапредупреждающего") для снижения риска высокой неопределенности при старте проекта!

Технически это прежде всего связано с постановкой и мониторингом специальных процедур (по ISO, PM BoK  или СММ), которые , собственно, и обеспечивают качество проекта- см. Рис.24

Рис. 24 Процессы обеспечения качества проекта в соответствии с требованиями ISO 9000 и модели СММ

В то же время отказ от управления качеством вообще может привести реализации очень опасных рисков и , даже, к провалу всего проекта . Это наиболее характерно как раз для больших проектов внедрения ERP-систем. Возьму на себя смелость предположить, что широко публикуемый в ИТ -литературе процент неудачных ИТ-проектов ( по разным данным от 78 до 84 %)  является, как раз следствием, либо отсутствия , либо не выполнения QA -плана!  

  Внедрение вообще всех типов интегрированных ERP-систем является хорошим примером проекта, который как раз не вполне укладывается в традиционные рамки проектного подхода. Поэтому именно в таких проектах значения QA -плана возрастает многократно - в модели CMM  (оценка зрелости процессов разработки ИС  ),  предусматривается обязательное наличие QA- плана, разработка которого является одной из ключевых практик -Оценка (гарантирование) качества товаров и процессов (Process and Product Quality Assurance){3}.

И на первом месте в QA -плане идет, конечно, анализ рисков {7}.

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

На Рис .25 показан типовой ЖЦ проекта внедрения ИС ( например, Axapta) и соответствующие ему процессы выполнения проекта , при которых возможны "потери качества".

Рис . 25 Типовой ЖЦ проекта внедрения ИС и процессы при которых возможны "потери качества".

Вот почему QA -план в первую очередь ( ISO 9001) предусматривает обязательный анализ результатов каждой фазы ИТ-проекта прежде, чем стоит приступать к следующей.

Рассмотрим теперь, как можно реализовать требования модели СММ при организации проектного офиса на примере его реализации в среде MS Project -см. Табл.2

Табл.2 Пример Матрицы реализации требований модели СММ при управлении проектами разработки ПО или внедрения ИС с использованием информационной системы управления проектами (ИСУП) , построенной в среде  MS Project

Уровень модели СММ	Процессы	Комментарии
1 уровень Начальный (Initial)	Не определены	Неуправляемая разработка
2 уровень Уровень повторяемый (Repeatable)	Управление требованиями Requirements management	Требования к системе фиксируются и составляют единое целое с планом их реализации. Если требования изменяются, то изменяется план в MS Project. Требования документированы и выкладываются в проектную библиотеку MS Project.
	Планирование проектов Software project planning	Все задачи по реализации документируются в виде плана, который ведется в  MS Project Все дополнительные требования Потребителя документируются в виде запросов на изменения  ( CR ) и находятся в проектной библиотеке и отражаются в корректировках плана проекта в MS Project
	Отслеживание плана и периодический контроль Software project tracking and oversight	Документируется состояние проекта (выполнение задач) по результатам контрольных проверок. Результат проектного аудита  можно фиксировать  в MS Project в папке QA проектной библиотеки . Для  этих  целей  можно использовать Windows SharePoint Services
	Субконтрактное управление Software subcontract managment	Менеджер и исполнитель достигают договоренности о сроках (ценах) задачи. Задача может быть принята в план только при обоюдном согласии. Можно использовать Team Inbox (Team Assign) для автоматизации согласования плана в MS Project
	Контроль качества Software quality assurance	Группа контроля качества должна сравнивать результаты проекта с документированными требованиями. Результаты испытаний или тестирования сообщаются менеджеру и исполнителям. Требуется документировать ошибки в виде баг-листа и производить регрессивное тестирование. Протокол и акты выкладываются в проектную библиотеку MS Project
	Управление версиями и конфигурациями продукта Software configuration managment	Документируются изменения продукта в различных версиях. Существует описание отличий продукта от базовой версии. Во всех проектных документах ведется лист изменений  и все проектные документы находятся в проектной библиотеке MS Project Для  этих  целей  можно использовать Windows SharePoint Services
3 уровень Уровень определеный (Defined)	Настройка организационной структуры на процесс разработки Organization Process Focus	Проводится в соответствие с технологией ведения проектов организационная структура компании (создаются необходимые подразделения, перераспределяется ответственность). Ведется общий учет, как проектной информации, так и организационных мероприятий, таких как обучение, апробирование новых технологий. Производится стоимостная оценка задач, оценка новых трудоемкости процедур, сводятся результаты обучения, собираются планы всех групп. Данная информация должна быть размещена в централизованной базе данных проектного офиса, на основе данной статистики производится сравнительный анализ организации проектной деятельности. Для  этих  целей  можно использовать Windows SharePoint Services В качестве  базы совместного планирования можно использовать MS Project Central. Необходимо создать в нем межпроектный пул ресурсов.
	Описание организационного процесса разработки Organization Process Definition	Документируется стандартный процесс разработки. Документы и статистика по организации процесса собираются в едином хранилище MS Project на проектном сервере . Для  этих  целей  можно использовать Windows SharePoint Services Периодически по результатам статистических наблюдений за выполнением планов и стоимостей работ производится пересмотр элементов стандартного процесса разработки.
	Программа обучения Traning Program	Согласно потребностям проектов составляется программа обучения. Ведется учет результатов тестирований и сертификаций. Производится периодический аудит программ обучения. Если не зарезервировать время на обучение, то персонал будет самообучаться для проектных целей. Это приведет к "непонятным" потерям времени (неуправляемости проекта), низкому качеству получения знаний.Процесс обучения отражается в MS Project в виде задач.
	Интегрированное управление проектами и технологией Integrated Software Managment	При планировании проектов используется документированный стандарт процесса разработки. По документированной процедуре прилагающейся к технологии разработки используется оценка рисков, критического пути, стоимости и продолжительности работ. Разрабатываемые планы учитываются в специальной  базе данных проектного сервера. Полезна выработка шаблонных документов для ТЗ, договора  , Устава проекта и т.д. Для оценки рисков по PERT-технике и определения критического пути можно использовать MS Project.
	Технология разработки Software product engineering	Документируется технология разработки. Описанные технологические стадии используются при планировании. Технология должна описывать: аналитику (прототипирования, декомпозиция, модели, сценарные описания) хранение исходных текстов версии системы кодирование (структурирование и повторное использование) тестирование и верификация: модульное и интеграционное тестирование, системное тестирование , инспекции кода, тесты соответствия. организация документирования На базе документированной технологии строится план. Ведется учет дефектов выявляемых тестированием и результатов рецензирования проектных документов (peer reviews). В MS Project необходимо выделить отдельные технологические стадии (аналитика, проектирование и т.д.) в виде mile stone (контрольных точек).
	Межгрупповое управление Intergroup Coordination	Требования пользователя утверждаются для реализации в продукт всеми группами разработки. Руководитель проекта отлеживает выявление проблем и мониторит их статус при помощи задач подготовки статус-отчетов в MS Project.
	Периодический осмотр технологического состояния Peer reviews	Производится технологическая инспекция состояния проектов. Выявленные дефекты регистрируются. Проводится рецензирование всех  проектных документов в проектной библиотеке MS Project
4 уровень Уровень управляемый (Managed)	Метрический Процесс Управления Разработкой Quantitative Process Managment	По учетной информации обеспечиваемой Level 4 ведется всесторонняя статистика. Вычисляются эталонные статистические показатели стандартного процесса разработки или внедрения. На основе сравнения с ними ведется управление проектами. Для  этих  целей  можно использовать Windows SharePoint Services На данном этапе нужно воспользоваться накопленной статистикой ведения проектов в MS Project. Построив статистические отчеты по различным технологическим стадиям, можно получить реальные и проверенные практикой оценки трудоемкостей. Их следует использовать в качестве эталонных при последующем планировании в MS Project.
	Управление Качеством Software Quality Managment	Разрабатывается и мониторится План обеспечения качества -QA-план Ведется статистический анализ различных параметров качества процессов и внедряемой системы. Полученные данные сравниваются с эталонными показателями. На основе полученных данных вносятся коррекции в технологических процесс и методы реализации проектов. На данном этапе необходимо базу регистрации дефектов интегрировать с SQL Server и получить статистику по видам дефектов результаты бубликуются в библиотеке MS Project.
5 уровень Уровень оптимизиро ванный (Optimizing)	Предотвращение дефектов Defect Prevention	Ведется анализ и статистический учет причин возникновения проблем или дефектов. Выявленные причины  ранжируются по приоритетам и устраняются организационными мероприятиями. Результаы корректирующих действий документируются в проектной библиотеке MS Project Для  этих  целей  можно использовать Windows SharePoint Services
	Управление сменой технологий Technology Change Managment	Производится плановое апробирование новых технологий. Результаты апробирования регистрируются. Производится плановое внедрение новых технологий, которые показали высокие результаты. Для целей регистрации результатов апробирования можно использовать Windows SharePoint Services

На Рис. 26 показан пример  необходимого для обеспечения качества проекта взаимодействия функционалов проектного офиса и системы менеджмента качества (СМК).

Рис. 26 Схема взаимодействия проектного офиса и СМК (ARIS)

Рассмотрим , например , ИТ-проект в разрезе деятельности телекоммуникационной компании. Для прочих отраслевых сегментов ИТ являются инструментами управления и обеспечения жизнедеятельности, а для телекоммуникаций - это активы, используя которые эти компании непосредственно зарабатывают деньги. Конечно , ИС позволяют автоматизировать процессы, сократить текущие расходы и повысить производительность труда. Но главной функцией ИТ в телекоме , все же  остается предоставление услуг. В данном контексте весьма нагляден процесс развертывания мульти-сервисных сетей у телекоммуникационных операторов. Они уже изначально проектируются как сети двойного назначения, поскольку одновременно служат и для решения внутрикорпоративных задач, и для обеспечения коммерческих услуг связи. Разница между заводом и оператором связи наблюдается не только в функциональности, но и динамике потребностей, скорости внедрения и других качественных параметрах внедряемых ИТ-решений ( например, лидерам мобильной связи, обслуживающим миллионы абонентов и обрабатывающим уже сотни миллионов записей о регистрируемых событиях в месяц, нужны хранилища данных на десятки терабайт). Ядром ИС для таких компаний является биллинг . А архитектура современных биллинговых систем становится чрезвычайно сложной, так как должна обеспечить поддержку мультисервисных услуг. Биллинговые системы должны уметь снимать записи о событиях не только с обычных телефонных станций, но и с коммутаторов мобильной связи, шлюзов IP-телефонии, серверов доступа и т.д. Все эти данные нужно обрабатывать и представлять в виде единого счета. И ошибка на каждом этапе внедрения и, особенно, на первых,  чревата большими убытками.

Вот, где особенно необходим QA-план !

Другая особенность ИТ-проектов, как уже отмечалось ранее, и которая очень сильно влияет на качество -это персонал проектной команды. Как правило, в сфере ИТ работают люди с высоким интеллектом, большим объемом специфических знаний и, самое главное, с острым чувством независимости. Такими людьми непросто управлять, так как их довольно сложно мотивировать. Чтобы полноценно "реализовать" ИТ-специалиста на проекте, необходимо задействовать весь арсенал системы мотивации: от идеи "пощупать" новую технологию и поработать в хорошей команде до морального и финансового поощрения по итогам успешного окончания проекта. Но с другой стороны высокие требования к квалификации, например, программиста почему-то говорит мне о плохом менеджменте проекта. В идеале, хорошо структурированный проект , например,  разработки или интеграции ПО , должен быть разбит на такие маленькие кусочки (согласно flow chart), что для кодирования  каждого кусочка должно быть достаточно квалификации выпускника вуза-это прямой результат качественно спланированного проекта {7}.

А вот для разработки архитектуры ИС уже необходим высокий класс и опыт!

Вот это правило ( как можно более детальное планирование ), как раз и является одним из методов обеспечения качества результата {7}.

Таким образом, проектная форма внедрения ИС с помощью QA-плана становится инструментом обеспечения качества внедренной системы { 1,6}.

Понятно, что реализации процессов QA необходимо обеспечить необходимое  взаимодействие всех участников проекта. Для этого нужно реализовать правильную модель коммуникаций с Заказчиком { 1,6}.

В целом модель необходимой организации взаимодействия команды Исполнителя и Заказчика для обеспечения качества проекта представлена на Рис. 27

Рис . 27 Организация взаимодействия команды Исполнителя и Заказчика для обеспечения качества проекта

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

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

В таких случаях, конечно, никакой QA -план делу уже не поможет .

8. Как измерить  эффективность СМК

"Есть много вещей, о которых

нужно подумать наперед".
Ямамото Цунэтомо, "Хагакурэ"

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

Cертифицируется же система качества чаще всего сразу после подготовки необходимых документов.

Поэтому ни о какой динамике улучшения показателей тут речи быть не может.

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

Так как-же, все-таки, измерить нам реальную эффективность СМК путем  анализа динамики ее показателей?

Все такие работы сводятся к оценке затрат на обеспечение качества, а вот как измерить эффективность работы именно самой СМК?

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

Матрица возможных ПК для проектной деятельности ИТ-Компании приведена в Табл. 3

Табл. 3

№ №	Наименование ПК	Обозна чение ПК	Что показывает и характеризует	Как рассчитывается
1	Экономическая эффективность сотрудника	S , $\час	Степень эффективности внутренней организации Бизнес- процессов Компании	S=(доход Компании от выполнения проектов)/ (суммарное время работы проектных команд в выполненных проектах)
2	Степень утилизации сотрудника	U , %	Степень внутренней связности  и оптимизации Бизнес- процессов Компании	U=( время работы в проекте)/( календарное рабочее время)
3	Доля проектов превысивших свою плановую себестоимость	C, %	Степень эффективности управления ресурсами для обеспечения  Бизнес процессов Компании	С=( количество проектов превысивших свою себестоимость)/(общее количество проектов)
4	Доля  проектов превысивших свою плановую длительность	D,%	Степень эффективности планирования и управления выполнением ИТ-проектов Компании	D=( количество проектов превысивших свою длительность)/(общее количество проектов)

Введем  интегрированный показатель эффективности СМК  -Q, который будем считать равным 100 при достижении всеми перечисленными показателями своих нормативных значений.  

Тогда суммарное отклонение в СМК от запланированных целей - dQ, можно рассчитывать по формуле (1):

dQ = dD+ dC+ dU+ dS ,                         ( 1)

где:  d = ( Mo -M)/ Mo ,  M и  Mo - соответственно текущее и запланированное значения конкретного ( одного из перечисленных)  показателя ,  

а :  dD, dC,  dU,  dS ,  - обозначения текущих отклонений по соответствующим показателям -см . Табл.  2

Понятно, что при Q =100 ,    dD= dC= dU= dS= dQ=0.

Например, текущее и нормативное значение отклонений и пример результатов расчета Q приведены в Табл. 4 (Все цифры для нормы взяты с "потолка" только для примера расчета)

Табл. 4

№ №	Обозначение ПК	Обоз начение отклонения	Норма (при мер)	Текущее значение в 1 квартале (пример)	Величина отклонения в 1 кв  d,%	Текущее значение в 2 квартале (пример)	Величина отклонения в 2 кв  d,%
1	S , $\час	dS	56	38	-31	43	-23
2	U , %	dU	70	49	-30	59	-16
3	C, %	dC	85	68	-20	75	-12
4	D,%	dD	60	70	+17	58	-3
5	Q	dQ	100	35	-65	46	-54

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

Рис. 28 (а) Пример диаграммы

динамики достижения целей в области качества

Но можно пойти еще дальще - попытатся оценить и экономический эффект от работы СМК .

Сделать это можно, например, следующим образом.

Введем   показатель экономической эффективности СМК  -SQ , который можно  рассчитывать, например,  по такой  формуле (2):

SQ= ( S * U * N * T *  (100-С)* (100-D)) /  1000*K ,                               (2)

Где : T - календарный период в рабочих часах , за который оценивается SQ;

1000 - множитель, учитывающий измерение С, D и U в " % ";

N - суммарное количество сотрудников, учавствующих в выполнении проектов;

K  ( в $ )- затраты на обеспечение качества , которые можно оценить исходя из формулы (3):

K = ( А + Д + П ) * R + Р;                                     (3)

Где :   R - средняя по Компании почасовая ставка сотрудника , $\час;

А  - суммарные затраты в человеко-часах на проведение аудитов СМК,

А = n * Ао , n - суммарное количество проведенный аудитов, Ао - средняя величина трудозатрат  в часах на один аудит ( здесь все понятно) ;

Д -  затраты в человеко-часах на управление документацией СМК ( это время, которое тратится  на поддержание документов в актуальном состоянии - анализ требуемых изменений , корректировка и публикация новых версий),

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

П=m * По , m - количество проведенных совещаний , По - средняя величина трудозатрат в часах на одно совещание;

Р -  прочие расходы в рамках СМК в $ , например, на обучение, участие в семинарах, приобретение литературы и т.п .  

Для иллюстрации приведен пример расчета SQ по  исходным данным некоторого примера - см. Табл. 5 .    

Табл. 5

Величина	1 квартал	2 квартал	3 квартал
С, %	68	58	55
D,%	70	65	60
U,%	49	59	64
S, $\час	38	43	46
T,  час	500	504	504
N	120	135	140
R, $\час	20	20	20
Ао, час	4	4	4
n	10	11	12
А,  час	40	44	48
Д , час	10	10	10
По , час	10	10	10
m	35	40	42
П, час	350	400	420
Р , $	0	0	0
K , $	8000	9080	9560
SQ	13,4	27,9	39,1

Полученные в примере значения SQ в зависимости от времени означают, что при наличии постоянного контроля ( аудиты ) и анализа степени соответствия проектных результатов требованиям Потребителя ( совещания проектных групп) происходит  постоянное увеличение прибыли Компании за счет эффективной организации и взаимосвязанности ее Бизнес-процессов , планирования ресурсов на основе опыта предыдущих проектов - см. рост SQ по каварталам ( см Рис 28(б))!

Рис. 28 (б) Пример диаграммы

динамики коэффициетна эффективности СМК

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

9. Человеческий фактор

Только нравственно совершенный человек,

имеющий  христианскую любовь к ближним

и Отечеству,  может сотворить  совершенное

произведение в области техники,

социально-экономической жизни,  и других сферах.

Иван Ильин, "Стремление к очевидному".

Во всех социотехнических  системах в качестве активного элемента системы задействован человеческий фактор.

Вспомним,  как трактует это понятие советская энциклопедия:

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

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

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

Посмотрите внимательно , как определяет международный терминологический стандарт ( пусть и устаревший в настоящее время, но это , пожалуй , самая удачная формулировка ) ISO 8402 смысл СМК:

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

Именно "сотрудничество" для "успеха" и "выгоды".

Поэтому, первые шаги в формировании нужной ''организационной культуры'' компании для создания СМК должны быть связаны именно с прояснением и закреплением высших ценностных установок.

И первым кирпичом в здании ''организационной культуры''  в этом направлении является формулирование Политики Качества Компании.

Да -  это декларация.

Или манифест, если хотите.

Но она  служит своеобразным  "знаменем полка" для Компании.

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

А  создание СМК обязательно потребует определенных изменений в Компании.

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

Поэтому СМК хороши или совершенны настолько, насколько профессиональны и совершенны люди их создающие.

На Рис. 29 автор  попробовал изобразить существующие методы повышения качества производственной деятельности  и степень необходимости их использования при построении СМК.

Рис. 29

Но мало провозгласить Политику - надо еще сформировать  продуктивную организационную культуру, направленную  на достижение поставленных целей .

А создание  производственной культуры требует не одного года,  в то время, как на внедрение СМК Руководством отводиться  всего несколько месяцев . Вот и получается пресловутое: "Хотели, как лучше, а получилось, как всегда!"

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

Роль процессов вовлечения персонала, усиления его роли (а это, прежде всего, его ответственность) в обеспечении качества, процесс делегирования прав и  полномочий  прямо сформулирована в требованиях к СМК {1 }. Чем выше степень участия персонала в управлении, в том числе качеством, тем больше должно быть делегировано ему прав и полномочий ( и тем выше, соответственно, его ответственность за свою работу).

То есть, речь идет прежде всего о воспитании в Компании Нравственно надежного персонала ( ННП) .

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

ННП отличает, высокий уровень технологической и исполнительской дисциплины, профессионализм и компетентность, способность к самоорганизации и самоконтролю. А это опять, именно то, что необходимо для эффективной СМК!

Нужно прекрасно понимать, что без этого, никакая система улучшения чего-то ни-было работать просто не будет -все, что мы построим , рано или поздно окажется просто бутафорией!

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

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

делать для других так, как Вам хотелось, чтобы сделали для Вас!

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

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

Наиболее часто встречающиеся факторы такой демотивации хорошо известны и  представлены нами   на Рис. 30 .

Рис. 30 .

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

Поэтому роль вовлечения персонала, усиления его ответственности  в обеспечении качества производственных процессов, делегирование прав и  полномочий  прямо сформулирована в требованиях к СМК {1 }. Чем выше степень участия персонала в управлении, в том числе качеством, тем больше должно быть делегировано ему прав и полномочий ( и тем выше, соответственно, его ответственность за свою работу: кому много дано, с тех много и спрашивают).

Не признать ключевую роль HR в системе управления качеством просто невозможно.

Это действительно все понимают.

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

Можно прямо сформулировать лозунг: "в СМК персонал решает все!"

Для своевременного принятия адекватных решений в условиях быстро меняющегося рынка, важно уметь пользоваться огромным багажом знаний, которым располагает практически любая современная компания. Однако без СМК невозможно эффективное использование информации, рассредоточенной в головах сотрудников, базах данных, хранилищах документов, сообщениях электронной почты, отчетах о продажах, данных о клиентах, партнерах и конкурентах Вашего предприятия. Эти накопленные знания  в систематизированном  виде эффективно используются только в СМК { 1}!

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

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

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

Для этого и решается  такая непростая задача - выстроить политику оплаты труда, которая была бы основана на реальном весе должности, на результате, на оценке индивидуального вклада каждого сотрудника !

В качестве практического примера приведу вариант системы мотивации из хорошо мне знакомой ИТ- отрасли.

Основная идея лежит в ведении показателя  "Личный рейтинг сотрудника".

Личный Рейтинг сотрудника ( ЛРС  ) должен зависить, по крайней мере от двух основных составляющих:

• от его реальной утилизации ( например за год ) -  это часто уже используемый в компании показатель U,

• от его потенциала- знаний и опыта их реализации -обозначим такой новый показатель, как NC (расшифруем ниже).

Алгоритм определения ЛРС представлен на Рис. 31

Рис. 31 Алгоритм ЖЦ  показателя RU

На Рис 32 показана петля качества для понятия личный рейтинг сотрудника.

Рис. 32 Петля качества для понятия личный рецйтинг сотрудника

Показатель личного рейтинга для сотрудников Проектных подразделений предлагается в виде следующего соотношения:

RU = (Суммарная  занятость в проектах за год в ч\д) / ( Календарное рабочее время за год в ч\д)*( коэффициент личного опыта и  специализаций  сотрудника)  

Или

RU = (Тп \ Тр)*NC = U * NC ,

где: U = Тп \ Тр - утилизация сотрудника ,Тп -суммарная  занятость в проектах в ч\д , Тр- календарное рабочее время в ч\д , NC - коэффициент опыта и  специализаций, которыми владеет сотрудник.

Расчет Коэффициента NC проводится на основании данных  личной матрицы знаний и опыта сотрудника (МЗО), формат которой приведен в примерах -Табл . 6

Примечание: cтатус подтверждения -это может быть, либо подпись Руководителя Департамента ( ПРД), либо наличие сертификата.

Табл . 6 ФИО  -Иванов Иван Иванович , U =60% ( за год )

№№	Область знаний	Специализация знаний	Статус подтверждения	Количество проектов , где был опыт применения
1	Управление проектами	Руководитель проекта	сертификат	2
2	Функциональность системы SAP	Модуль FI	сертификат	2
3	Функциональность системы SAP	Модуль CO	сертификат	1
4	Моделирование Бизнес-процессов	ARIS	ПРД	1
5	Моделирование Бизнес-процессов	BP Win	ПРД	0
6	Бухгалтерский учет	GAAP	сертификат	3
		ИТОГО  M= 6		ИТОГО  N =9

Где: М -это число специализаций сотрудника  , N -число проектов, где эти специализации были востребованы.

Для представленной МЗО коэффициент NC будет определятся следующим образом:

NC = ( M * N)=  6*9 = 54

Так, например, для приведеного примера в случае  И.И. Иванова (   имееет среднюю личную утилизацию за год  60%) ,   его личный рейтинг составит:

RU = 0,60 *  54 = 32,4

Безусловно, для любой ИТ-компании приоритетна и внутренняя ротация.

Это просто более выгодно экономически.

Если мы приглашаем менеджера со стороны, то мы оплачиваем его поиск, проводим адаптацию и только через 1-1,5 года можем ожидать от него каких-то результатов. Получается очень продолжительный во времени и очень затратный процесс. А если мы человека последовательно растим внутри компании, мы хорошо знаем его слабые и сильные стороны, мы знаем, как с ним эффективно взаимодействовать, и он, как правило, лоялен, знаком с корпоративной культурой. Этот процесс очень выгоден и для людей, и для компании.

И ,напротив, заметная текучесть кадров в ИТ -компании может привести ее даже к катастрофе- однажды глава Microsoft  Билл Гейтс сказал, что увольнение 10% сотрудников приведет его компанию к краху, а Руководство Oracle считает необходимым  сохранять примерно 90% сотрудников подразделений разработки и техподдержки  , чтобы обеспечить непрерывность процесса совершенствования и круглосуточной поддержки своих программных продуктов!

И еще.

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

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

Однако еще значительная часть Руководителей быстрорастущих ИТ-Компаний продолжает реализовывать "семейный стиль" управления, который приносил результаты при численности 50-80 человек и совершенно не подходит к Компаниям, где число сотрудников перевалило за 300  человек ! В этом случае  становится просто необходимым реально использовать все технологии управления качеством ( ISO 9001) и персоналом!

Однако многие директора по качеству ( QA-Директор  ) и директора по персоналу ( HR- Директор ) справедливо считают {2}, что руководство их компаний не до конца понимает цели и задачи и службы качества и службы персонала, а их место в управленческой структуре вообще не определено.

Как показал опрос Всероссийского кадрового конгресса {10}, практически каждый третий HR-менеджер жалуется, что у него мало полномочий и возможностей влиять на стратегию развития компании.

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

90% участников опроса главной причиной назвали отсутствие у руководства компании четких представлений о том, зачем нужна служба персонала. Следствие такого недопонимания - низкий уровень делегируемых HR-менеджеру полномочий и недостаточный бюджет, выделяемый на работу с персоналом {10}.

Мы думаем , что то-же самое может сказать и каждый второй QA-менеджер!
В то же время объективно уже возникла двусторонняя потребность в глубокой интеграции QA-и  HR-  служб в бизнес на более серьезных правах - правах партнера, заинтересованного в росте эффективности бизнеса. Об этом свидетельствует преобладающее мнение топ-менеджеров о том, что во всех аспектах управления Компанией  качество процессов и реальная вовлеченность персонала и , особенно, менеджеров должны взять приоритет над количеством, а среди актуальных проблем звучат: мотивация персонала на эффективность и результат, успешная реструктуризация, оценка стоимости персонала (как объекта затрат, с одной стороны, как актива, создающего стоимость, - с другой).

В компаниях, где это понимают обе должности ( Директор по  качеству  и  Директор по  персоналу) уже давно и  тесно сотрудничают .

10. СМК- это готовая система управления знаниями Компании

"Зри в корень"

К. Прутков.

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

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

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

В связи с этим сразу встает вопрос об организации системы управления знаниями (СУЗ), как полученными вновь, так и накопленными ранее .

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

На  тему  СУЗ существует огромное множество работ самого разного масштаба.

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

Тем не менее, возьму на себя ответственность представить  СМК, как систему, выполняющую еще и функции системы управления   знаниями ( СУЗ) в том числе.

Я утверждаю, что одной из методик организовать накопление и совершенствование знаний и квалификации персонала в Компании, как раз и является внедрение СМК.

Ведь  качество в понятиях  СМК , это не качество продукта , а качество процессов его создания {1}.

Это архиважно для последущих рассуждений.

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

Знание - это Опыт, Информация, Идеи и Отношения, используемые для осуществления трудовой деятельности. Самым важным примером знаний является опыт, накапливаемый сотрудниками компании по мере их работы. Знания постоянно циркулируют в каждой компании. Ежедневно, мы встречаемся, обсуждаем, советуемся, сплетничаем. Обмен знаниями происходит постоянно - Non Stop  .

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

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

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

Бизнес-процессы ( БП ) - это имеющиеся у любого предприятия процедуры, методы, технологии, с помощью которых оно функционирует, то есть извлекает доход из своей деятельности.

Качество БП  - это выполнение производственной деятельности в соответствии с  установленными в Компании   технологиями.

В СМК эти знания должны быть документированы в виде описания процессов деятельности (инструкции, методики и т.п. ) и управляемы по определению {1}  . Не документированные  знания - это лишь профессиональная интуиция, которая является только производной от накопленного производственного опыта.

Снова вспомним  закон "80\20". И в области управления знаниями он работает тоже - специалисты считают, что в организациях в той или иной форме используются только 20% всех знаний, которые становятся "явными".  Это означает, однако, что 80% остаются невостребованными.

Они остаются в головах сотрудников .

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

Документация СМК -это, как-бы , корпоративная   память, которая, по аналогии с человеческой памятью, позволяет пользоваться предыдущим опытом и избегать повторения ошибок!

Зачем оно нам надо?

Потому,  что "Кадры решают все".

Первое . Как бы не был устроен Ваш бизнес, качество работы, напрямую зависит от квалификации персонала. Это мнение подтверждает и глава Microsoft Билл Гейтс, утверждая, что смена 10 % состава приведет его компанию к банкротству.

Он знает, что говорит!

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

Второе . "За одного битого - двух небитых дают". Так гласит народная мудрость, а народ у нас, как известно, очень мудрый. Каждый из нас прекрасно знает, чем более опытный сотрудник, тем более качественно выполняется работа (ну за очень редким исключением). Почему? Потому, что разница между теорией и практикой может быть просто огромной!

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

Вспомнив определения технологии и знаний, мы можем понять, что технология является производной от знаний. А качество БП  - производной от соблюдения технологий . И без СМК другой сотрудник опять может наступать на те же грабли. Оно Вам надо?

Почему  СМК  всегда  будет приносить эффект ?

Попробую ответить и на это .

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

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

Это основа эволюции.

И  основный принцип   СМК -см. выше Рис.2.

Система управления качеством - это и есть готовая система управления знаниями !

Как управляют знаниями в СМК ?

Знание проходит несколько этапов жизненного цикла: создание, анализ, документирование,  использование и :. Забывание- см. Рис. 33.

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

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

На этапе документирования - формулируются выводы. Результатом анализа и документирования и является создание технологий -Know How.

Очевидно, что зафиксированные в технологиях знания и нужно  использовать при выполнении БП. Именно поэтому все необходимые знания Компании СМК требует  документировать  {1}!

Важным этапом является забывание. Если компания использует СМК , то забывания в его основном смысле уже не будет -см. Рис. 33 !

Будет замена устаревших ( не нужных Компании ) на новые, и  при создании новых  версий знаний  - старые просто архивируются, но не пропадают !

Рис. 33

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

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

И именно поэтому назначение Директора по качеству ( см. ниже п. 15), как владельца СМК, может рассматриваться, как первый тест, который показывает, насколько руководство заинтересовано в успехе внедрения такой  важной и необходимой системы.

11. Аудиторы идут

"Есть много вещей, о которых

нужно подумать наперед".
Ямамото Цунэтомо, "Хагакурэ"

На  тему  разработки и внедрения СМК существует огромное множество работ самого разного масштаба. А вот вопросу подготовки персонала к аудитам уделено внимания гораздо меньше.

А вопрос этот мне представляется крайне важным, по крайней мере, уже по той причине, что в процессе такой подготовки происходит дополнительное обучение  сотрудников основным методам и принципам СМК!

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

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

Лучше один раз посмотреть, чем сто раз прочитать!

Этот принцип я рекомендую и положить в основу подхода к обучению . Поэтому я предлагаю изготовить  (только  в качестве примера по представленным Рис. 34-36, полагая, что их можно нарисовать и более системно) несколько рисунков или  слайдов ( или плакатов для проведения подготовительных собраний персонала перед аудитом ), которые можно оформить и в виде "Памятки Сотруднику об СМК" .

Каждый Плакат ( рисунок, слайд) будет отвечать на следующие системные вопросы по СМК.

Что и Как проверяют?

На Рис.34 в стилизованном виде для ответа на этот вопрос, показано:

• Общая структура СМК в Компании;

• Взаимодействие Службы качества, Подразделений и группы внутренних аудиторов ( ВА ) ;

• Роль и место Службы качества и группы  ВА ;

• Направления  и способы проверки СМК при внешнем аудите;

Рис.34.

Что Сделано (что хотят услышать) ?

На Рис. 35 ( а )  в стилизованном виде для ответа на этот вопрос, показано, что:

• В Компании для выполнения основных требований Стандарта:

• Разработана Политика и Цели,

• Описаны необходимые Бизнес-процессы (БП) Компании,

• Разработаны процедуры анализа требований Потребителей,

• Разработаны методики и процедуры анализа удовлетворенности  Потребителей,

• Проводится анализ данных и показателей БП;

• Проводится мониторинг требований и удовлетворенности Потребителей;

• Планируются улучшения БП.

(БП  - это имеющиеся у любого предприятия процедуры, методы, технологии, с помощью которых оно функционирует, то есть извлекает доход из своей деятельности).

Рис. 35 ( а).

На Рис. 35 ( б) показано, что понятие Потребитель распространяется и на взаимодействия  внутри Вашей Компании .

Рис. 35 ( б )

Что хотят увидеть?

На Рис. 36  в стилизованном виде для ответа на этот вопрос, показано, что обязательно необходимо показать аудиторам:

• Цели и показатели их достижения;

• Методики и Отчеты по  анализу удовлетворенности  Потребителей,

• Текущие значения показателей БП;

• Схемы и регламенты выполнения БП;

• Планы по достижению целей и Планы по улучшению деятельности;

• Документы подтверждающие анализ требований Потребителя ( ТЗ, договора и т.д.);

• Отчет по анализу СМК;

• Понимание смысла и необходимости СМК персоналом;

• Знание персоналом документации СМК.

Рис. 36.

Показанные Рисунки - это пример наглядного видеоряда, который с успехом использовался мной в некоторых Компаниях .

    

12. Что остается "за кадром" ее внедрения

"Кто искусен в изменениях -

тому не страшен хаос!"

Народная китайская мудрость

Кто и как внедряет СМК ?

Этим, конечно , занимается Отдел или Служба качества.

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

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

А вот правильное понимание этой ситуации Руководством всегда остается за кадром.

А сама жизнь подсказала  удачный вариант совмещения такого понимания  и желания Руководством   внедрять СМК - это введение должности Директора ( или зам. директора ) по Качеству.

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

Кто и как заинтересован во внедрении СМК ?

Ну, Потребители, понятно - по определению {1} .

А вот заинтересованность   руководства и персонала   всегда остается за кадром!

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

Понятно, что у сотрудников  тоже есть свои интересы.

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

С качеством для потребителя, кажется, всё ясно: это то, за что он хочет и может платить деньги. А что есть качество для владельца Компании? С ним кстати тоже просто -он хочет получать дивиденды, как можно большие и как можно дольше. Что же касается сотрудников, то для них качество - это и хорошая зарплата , и корпоративная культура, и интерес к работе и т.д.

Но практика показывает, что, как правило,  внедрение СМК:

• не приводит к увеличению дивидентов - значит нет заинтересованности

Владельца  ;

• не поднимает зарплату персоналу и не повышает его интерес к работе - значит  нет заинтересованности Сотрудников .

Интервью с руководителями и ответственными специалистами и анализ документов показывают, что работа по выполнению требований СМК в части анализа процессов и принятия решений является дополнительным бременем для них. Работа, в основном,  ведется по привычной схеме: "найти  и наказать ".

То, что  любая работа персонала в рамках СМК , воспринимается сотрудниками, как "дополнительная", добавленная к "основной" деятельности -   всегда остается за кадром!

А если нет  заинтересованности исполнителей СМК, то как она будет развиваться ?

А никак и не будет.

И тому просто масса примеров!

Поэтому ,  как уже упоминалось выше , если позвонить в 100 Российских организаций через, скажем,  полгода после получения ими сертификата ISO 9000 на их СМК,  и поинтересоваться, ну , например, в отделе продаж ( сбыта ), или секретариате, или в службе технической поддержки,  о наличии СМК, то  в 90% случаев Вас спросят: " А что это такое ?"

А что тогда делать?

Мотивировать персонал надо! О мотивации  всегда говорят , либо вскользь , либо предпочитают не упоминать вовсе.

Мотивировка персонала в СМК   всегда остается за кадром!

И понятно почему - и так постоянные внутренние проверки и регулярный сбор, расчет и анализ данных отнимает много рабочего времени,  а тут еще за это плати ! Какому руководителю такое понравится?

А это вовсе не второстепенный фактор - ведь построить СМК можно и путем политического ( командирского)  решения Руководства , а вот  поддерживать и развивать можно только на основе заинтересованности самого персонала - см . выше Рис. 1 .

Здесь все зависит от того, что Вы хотите получить в результате. Хотите просто иметь сертификат ISO 9000 , то о мотивации можно и не вспоминать. Хотите действительно улучшений в работе ,  тогда надо серьезно думать - см . Рис. 1.

А теперь самый скользкий вопрос о том,  

Кто является Потребителем внедренной СМК?

Ну, Потребители, понятно - опять по определению {1} . А внутри Компании кто Потребитель?

Руководство?

А вот , и не факт.

Анализ деятельности руководителей по подготовке и использованию информации о ходе процессов, результатов анализа процессов и прочих документов СМК, как правило, показывает, что руководители получают информацию о ходе процессов, но не выполняют регламенты анализа  и принятия решения по отклонениям (т.е. цикл PDCA -cм. {1}). Руководители не проводят анализ процессов, не планируют мероприятия по улучшению процессов, не проводят предупреждающие действия. Внедряемая на предприятии СМК во многом является для них средством  распределения ответственности и полномочий, а не средством для эффективного управления.

Если  в  Компании  отсутствует    реальная  ( а не бутафорская - для получения сертификата ) система стратегических целей и показателей их достижения, увязанных с показателями оценки процессов , то руководство  и не будет мотивировано создавать более эффективную систему управления, основой которой и должна служить внедренная СМК.

То, что Руководство Компании не всегда является реальным  Потребителем СМК,  тоже часто остается за кадром!

На Рис. 37 на основе практического опыта внедрения СМК в Компаниях различного профиля и масштаба, сделана попытка провести экспертную оценку влияния всех, остающихся обычно за кадром факторов, на превращение внедренных СМК в бутафорские.

Рис. 37

13. Блеск и нищета стандарта ISO 9000

"Если делаешь что-нибудь неправильно -

не нужно рассчитывать на

правильный результат."
Народная китайская мудрость

Сегодня уже вопрос дня : как избежать создания бутафорских Систем Менеджмента Качества  -см. раздел 2?

Ведь совеншенно очевидно, что формальный подход к внедрению стандартов серии ISO 9000: 2000 {1} чреват потерей времени и средств, и самое неприятное - неоправданным разочарованием в самих стандартах , а ведь их содержание  выработано и уже проверено мировой практикой.

И действительно, при определенных условиях эти стандарты могут не только оказаться бесполезными, но и принести вред: при формальном подходе к их внедрению они только "отвлекают" персонал от работы.

По оценкам специалистов и руководителей организаций, до 80% предприятий, сертифицировавших системы качества по требованиям стандартов ISO  предыдущей серии 9000:1994, не получили ожидаемого эффекта.

Не повторится ли это и со стандартами ISO серии 9000:2000?

Этот вопрос вызывает большое беспокойство .

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

Стандарты ISO новой серии 9000:2000 носят ярко выраженный рыночный характер. А их главным достоинством является именно ориентация на потребителя.  

Поэтому освоение стандартов ISO серии 9000:2000 в нашей стране, где остро ощущается необходимость в создании конкурентоспособной продукции, безусловно и должно повысить эффективность работы предприятий в целом.

Вcе преимущества ( в смысле блеска ) новой версии стандартов ISO много раз обсуждались и хорошо известны- это и менеджмент ресурсов , и процессный подход  , и  лидерство руководства , и активное вовлечение персонала, и измерение показателей, и анализ эффективности и многое другое -см .Рис. 38.

Рис. 38. Достоинства и недостатки модели ISO 9000:2000

Поэтому гораздо интереснее поподробнее проанализировать другие  факторы ( в смысле нищеты) , которые   заложены в самом стандарте и  могут  привести  Компанию к созданию бутафорской СМК ( см . Рис. 38.)

Но  обсуждаются  вся эта "нищета"  у нас, и за рубежом чрезвычайно мало!

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

Ведь сам стандарт - это только скелет,  на который надо "нанизывать"  оптимизированые бизнес-процессы и их регламенты .

Результативность СМК зависит именно от целесообразности и "удачности " именно управленческих  решений.

А это  обеспечивается только знаниями, опытом ,  профессионализмом руководителей и специалистов и  арсеналом методов , которыми они владеют,  а не знанием требований стандарта!

Далее .

Cтандарт несет принцип : "документируй , что делаешь и делай, как документировал".

Наряду с позитивным эффектом (упорядочение работ), это может также способствовать и формальному подходу к внедрению СМК.

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

А анализ результатов деятельности при этом смещается в сторону только проверки документов, а не оценки существа дела.

Далее .

Существует и реальная опасность того что,  что и оценка СМК при ее сертификации идет именно по формальным признакам, даже если она проводится квалифицированными аудиторами. А она  и не может быть другой,  поскольку  стандарты предыдущей серии 9000:1994 были  ориентированы не на улучшение качества, а на сертификацию систем качества!

В стандартах  нет необходимых критериев для  оценки обоснованности принимаемых в рамках СМК  решений.

И еще про эффективность .

Для оценки эффективности СМК необходимо анализировать динамику показателей качества ( динамику достижения целей ). Cертифицируется же система качества чаще всего сразу после подготовки необходимых документов. Поэтому ни о какой динамике улучшения показателей, как уже было упомянуто выше , тут даже и речи быть не может и , соответственно ,  вопрос реальной эффективности даже и не ставится!

Далее .

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

Понятно , что при внедрении на предприятии стандартов ISO  серии 9000:2000

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

Далее, про политику  в области качества.

Не знаю, как другим консультантам , а автору постоянно приходится выслушивать негативные высказывания не только Руководства , но просто персонала по поводу нужности текста Политики . Может быть на Западе, с их менталитетом , это приемлимо, а для России, где все, что связано с лозунгами отторгается без всякого анализа, это явно не подходит. Более того , воспринимается все это,  как глупая формальность и сразу настраивает всех на чисто формальный подход. А это очень плохо,  и приходится долго обьяснять,  что это не очередные "первомайские лозунги", а только средство донести до персонала важность процесса .

Далее, по поводу адаптации к среде .

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

Вот почему во многих случаях высококачественная продукция становится в определенный момент просто невыгодной.

И в этом случае СМК становится просто нежизнеспособной (см. выше).

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

Далее , по поводу лидерства.

Здесь  опять уместно вспомнить именно про должность Директора по качеству, которая эффективно соединяет "магический" авторитет и полномочия руководителя со знаниями  и опытом менеджера по качеству. Именно Директор по качеству должен замкнуть на себя весь контур управления качеством и разгрузить этим Руководство компании -см .  далее .

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

Только Директор по качеству и может сделать СМК  эффективной и необходимой для  компании.

14. Что же надо конкретно Вам делать?

"Все великие идеи описываются

короткими словами"

Джек Траут

Введем понятие оптимальной модели системы качества -ОМСК.

Под оптимальностью здесь однозначно будем понимать получение запланированного результата при минимальной степени документирования, т.е. максимальную величину осоотношения = Результаты\ Степень документированности ( аналог всем известного соотношения =Цена \Качество).

Для того чтобы получить такую оптимальную модель ( далее ОМСК ) , мы рекомендуем  выстраивать работу по сценарию ( или Плану ),  приведенному на Рис. 39 .

Рис . 39

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

Далее необходимо спланировать действия по достижению поставленных целей (План достижения ) и описать существующий процессный ланшафт.

Процессный ланшафт представляет собой описание именно Ваших БП как минимум на верхнем уровне.

И только затем определить необходимые конкретные показатели БП , которые будут показывать степень достижения поставленных целей - вот это,  как раз,  и является основным посылом для выстраивания своих БП в состоянии "как должно быть"!

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

Вопрос перехода от состояния "Как есть" в  состояние  "как должно быть" всегда вызывает большие трудности - чем -же надо руководствоваться,  чтобы провести целесообразные изменения в структуре БП ?

На самом деле ничего сложного тут и нет - при этом переходе, как минимум,  в структуре БП необходимо:

• Обеспечить мониторинг всех выстроенных показателей ( контрольные точки  измерениия их метрик );

• Устранить искажения в структуре БП ( дублирование , несогласованность входов и выходов, лишние информационные объекты и т.д).

• Учесть требования процессного подхода ( контроль, анализ, корректирущие и предупреждающие действия) {1}-см. Приложение.

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

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

Теперь настало время определить регламент мониторинга и последующей оценки всех Ваших Показателей.

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

Состав и структура полученной в результате документации такой ОМСК по отношению к модели ISO 9000 представлена на Рис . 40

Рис . 40

ОМСК будет иметь значительно меньшую документированность, эффективность восприятия которой компенсируется наглядностью схем БП и процедур ( лучше один раз увидеть, чем сто раз прочитать) , и , тем самым , будет более понимаема и воспринимаема всем персоналом - см. Рис. 41 ( На рисунке для сравнения приведены данные и для модели СММ -степень воспринимаемости системы всегда обратно-пропорциональна количеству описывающих ее регламентов!)

Тут необходимо отметить, что концепция ОМСК целиком и полностью отражает лозунг : Эффективность - в упрощении!"и взгляды авторов {3}.

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

Рис . 41

В тоже время эффективность ОМСК будет, как минимум, на том -же уровне  поскольку она менее "забюрокрачена"и   более понимаема и , значит,  более воспринимаема , как конкретное руководство именно к практическим действиям  - см. Рис. 42 ( Для сравнения приведены данные и для модели СММ -степень достижения результатов по этой модели считается максимальной,  но при этом она содержит неизмеримо большее количество необходимых регламентов!)

Здесь следует обратить внимание на то, что это, именно "как минимум" - возьму на себя смелость предположить, что  ОМСК  может дать даже больший эффект, чем пресловутая модель ISO 9000,  так как, опять повторюсь,  -более понимаема!  

Рис . 42

Конечно, сертификат ISО 9000 на такую ОМСК  Вы  никогда не получите.

НО!

Вам легко и быстро ( 1-2 месяца ) можно будет формально достроить ( попросту написать лишь необходимые для сертификации текстовые документы ) ее до требований ISО 9000 - ведь основные ( и , безусловно , самые трудоемкие )  "правильные" требования этого стандарта у Вас уже выполнены ( процессный подход , показатели достижения целей и их мониторинг ).

Более  того , и это Вы теперь видите сами , именно это ядро СМК ( которое и описывает ОМСК ) и определяет собственно эффективность управления качеством, а не наличие текстового документа "Руководство по Качеству", которое Вы теперь легко сможете написать и сами!

В заключении этого раздела очень хочется дать графическоге описание  всего пути   Вашей Компании к достижению поставленных вами целей -см.  Рис .43.

Рис .43. Путь   Вашей Компании к достижению поставленных вами целей.

15. Роль и значение Директора по качеству

"Мудрость есть знание того,

что недостойно внимания"

Уильям Джеймс

Внедрение СМК, как известно, затрагивает все ее ключевые бизнес-процессы  .

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

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

Директор по качеству ( ДК ) - это топ-менеджер в современной компании, который и как раз и отвечает за правильную реализацию стратегии бизнеса через эффективную организацию всех внутренних БП Компании -см. выше Рис.10 .

В поле  деятельности ДК открываются два больших направления: автоматизация процессов управления всеми аспектами бизнеса от систем управления производством до систем управленческой отчетностью  и знаниями .

Но многим директорам российских Компаний  должность ДК  пока вообще ни о чем не говорит -  на большинстве предприятий эту роль де-факто относят разряду АХО или даже секретариата. И только на наиболее продвинутых компаниях, успевших достаточно тесно пообщаться с западными управленцами и начавших впитывать западные методы управления, начинает складываться понятие ДК.
ДК - это  интеллектуальный центр компании, связующее звено всех подразделений. Именно он профессиональный постановщик задач по интеграции и структуре сквозных БП Компании и именно он должен формировать требования к ИС внедряемым в Компании. Поэтому он должен иметь  не только хорошие знания в области ИТ и в  области производственной деятельности , но и системное мышление и   опыт Бизнес-моделирования -см. Рис. 44 .

Рис. 44

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

В этом и заключается корень успеха проекта внедрения СМК.

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

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

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

Поэтому , ДК должен быть прежде всего специалистом во всех аспектах бизнеса его компании, а не "начальником ОТК"- см. выше  Рис. 7 .

Вот тогда он и будет нести ответственность  за эффективность не только СМК,  но и всего бизнеса .

А если он знаком  только с требованиями стандарта ISO 9000, но не понимает организации всего бизнеса компании и не знает текущей стратегии его развития, то это наш типичный российский "менеджер по качеству",

который совершенно не подходит для руководства проектом разработки и внедрения СМК!!.

16. Структура и функции Службы качества

"Когда я пришел в Компанию, мне сказали,

что внедрением СМК Компания намерена

заняться всерьез и получить сертификат ISO 9000.

Когда я спросил, сколько человек будут работать

в проектной команде и  будут ли привлекаться

сторонние консультанты, мне сказали :

"Какой проект ? Вы  что, один не справитесь?"".

Из воспоминаний менеджера по качеству.

Служба качества ( СК) создается для реализации и поддержки процессов управления качеством .

Процессы управления качеством  (- см. Рис . 45 ) в общем виде можно подразделить на две группы:

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

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

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

Рис . 45 Структура процессов управления качеством в современной Компании.

Что касается конкретных дополнительных процессов за которые должна отвечать и  их контролировать СК , то изменения процессного ландшафта при внедрении СМК показано на Рис. 46

Рис. 46 За что именно отвечает СК , или что добавляет СМК в существующий процессный ландшафт .

Структура и основные функции типовой СК , в соответствии с новым процессным ландшафтом,  показаны на Рис. 47.

Здесь необходимо прокомментировать часто бытующе мнение, что не нужно создавать независимую СК , а достаточно ее функции распределить на выделенных (линейных ) менеджеров по качеству в каждом подразделении,  тем более, что модель ISO 9000  обязательного создания СК не требует!

Это очень коварное заблуждение - распределить -то, конечно , можно ( только для получения сертификата) , но реально работать такая "экономная схема" - поверьте практику- будет очень плохо ( и, скорее всего, через некоторое время вообще перестанет). Просмотрите внимательно  на Рис .47 !

Неужели Вы рискнете распределить такую важную , сложную и трудоемкую функциональность , как дополнительную к основной деятельности выделенного сотрудника?!

Рис. 47 Cтруктура и основные функции типовой  концепции управления качеством  

Очень часто на практике встает вопрос- а сколько сотрудников необходимо иметь, чтобы успешно управлять качеством?

Ответа на этот вопрос Вы нигде не получите, поскольку никаких норм на такую деятельность , конечно   , не существет.

НО .

Практика внедрения и успешного функционирования СМК показывает, что численность персонала СК может зависеть не только от размера Компании, но и от профиля ее деятельности - см. Рис .48.

Рис . 48 Рекомендуемая численность персонала СК в зависимости от профиля и размера Компании

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

БМП - это  как -бы паспорт подразделения ( см. Рис. 49.), в котром содержится вся необходимая для функционирования СМК информация:

• Функции и решаемые задачи;

• Структура ( штатное расписание );

• Показатели качества или эффективности его работы и их метрики;

• Диаграмма информационных потоков ;

• Описание БП его деятельности ( диаграммыБП );

• Перечень нормативных документов ( регулирующих эту деятельность);

• Определены поставщики и Потребители работ подразделения;

• Матрица ответственности персонала по всем функциям подразделения

• План достижения целей в области качества,

• План улучшения работы в подразделении.

Рис . 49. Структура Бизнес-модели подразделения

Методика, которой мы рекомендуем пользоваться   СК  для подготовки и сбора данных при  разработке БМП,  показана на Рис.50.

Рис . 50.  Методика  сбора даных для  разработки Бизнес-модели подразделения

Предлагаемая методика обеспечивает :

• наиболее эффективную для управления изменениями модульную структуру СМК ,

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

• Актуализацию необходимости информационных объектов и их потоков между подразделениями,

• распределение ответственности внутри самих подразделений без бюрократических  "Должностных инструкций",

• планирование достижения целей и улучшение деятельности непосредственно в самих подразделениях ( а не сверху),

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

• оперативный внутренний мониторинг показателей качества работы каждого подразделения Компании.

Полученная таким образом модульная структура СМК  имеет следующие преимущества:

• Процесс управления изменениями проходит внутри подразделения ( СК только контроллирует его наличие),

• Механизм взаимосвязывания и согласования входов и выходов БП становится более эффективным,

• Обеспечивает получение более достоверных значений показателей (заинтересованность самих исполнителей показать свою работу).

17. Какие стандарты можно  использовать для  СМК в  ИТ-области?

Одна из основополагающих идей TQM состоит в том, что мы можем управлять качеством разрабатываемого продукта в основном через процесс его изготовления. Качество продукта возрастает на каждой стадии процесса: во-первых, как прямое следствие зрелости и технологичности самого процесса, и во-вторых, вследствие использования промежуточного продукта, произведенного на предыдущей стадии, более высокого качества . То есть при сложном производстве качество накапливается в продукте кумулятивным образом, причем вклад в качество, сделанный на ранних стадиях, больше влияет на конечный продукт, чем вклад, сделанный на заключительных этапах. Процесс разработки должен быть построен таким образом, чтобы обеспечить возможность измерения качества продукта. В практике программирования, например,  наиболее часто в роли метрики качества продукта выступает остаточная плотность ошибок, то есть плотность ошибок на тысячу строк кода или на одну функциональную точку (FP). Однако если под качеством понимать степень удовлетворения требований, то мы должны измерять выполнение требований в конечном продукте. Это достигается организацией процесса разработки, предусматривающего создание на основе требований плана тестирования. Далее на основе плана должны быть разработаны тестовые задания (test cases), затем соответственно тесты и тестовые процедуры. В итоге обеспечивается полное тестирование всех требований и возможность измерения степени выполнения требований в готовящейся версии программы. Возможная "утечка" качества происходит в рассогласовании всех этих документов в сложных проектах. Обеспечение стабильности процесса возлагается на контроль качества, который должен выявлять несоответствия и информировать о них разработчиков и руководителей проекта.

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

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

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

Говоря об обеспечении  качества процессов именно в области ИТ, необходимо понять  реальное положение и соотношение всех известных (основных) стандартов, моделей, практик, методологий и руководств относительно их друг друга -см. Рис 51.

Рис. 51

Остановимся сначала на кратком описании всех упомянутых на Рис. 51 моделей и стандартов.

CMM (Capability Maturity Model ) разработана Software Engineering Institute при университете Карнеги-Меллона (США) и описывает модель зрелости процессов разработки программного обеспечения на предприятиях. В рамках этой модели  для каждой компании может быть сопоставлен некоторый уровень (один из пяти возможных), свидетельствующих о достигнутом качестве процесса разработки ПО. Так как эти стандарты разрабатывались, прежде всего, в целях упорядочивания процесса выбора подрядчиков для Министерства обороны США, особое внимание в них уделяется процессам управления ПО-проектами, в то время как технические аспекты разработки освещены меньше .

В версии SW-CMM v.1.1 (Capability Maturity Model for Software) имеется 316 Key Practices.

Key Practices - это то, что должно быть внедрено на предприятии и то, на что будет обращать внимание команда, проводящая оценку процессов. Они объединяются в области - Key Practices Areas ( KPA ) - это уже совокупности взаимосвязанных процессов, которые при совместном выполнении приводят к достижению определенного набора целей.

CMMI (Capability Maturity Model Integration) - дальнейшее развитие модели CMM. В CMMI-SE/SW Version 1.02 (CMMI for Systems Engineering/Software Engineering), пожалуй, наиболее приемлемой для разработчиков программных систем, - количество  Key Practices достигает уже 417.

Увеличение Key Practices связано с самой целью разработки CMMI - модель должна помочь избежать проблем, связанных с использованием различных отраслевых моделей CMM.

(Начиная с1991 года, были разработаны модели CMM для различных областей применения, наиболее существенными из них были:

- модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software - SW-CMM)
- модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard - EIA/IS 731)
- модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model - IPD-CMM)

На основе этих моделей и был построен CMMI. Он вобрал в себя лучшее из этих моделей, устранив неоднозначность трактования некоторых понятий ввиду наличия множества моделей - поэтому число ключевых практик значительно выросло).

Понятно, что это получилась уже существенно более "тяжелая" модель- см. Рис. 52 , которая еще не достаточно проверена ( вышла только в 2002 году ) на практике. В связи с этим при внедрении модели возможны большие риски, связанные, как с потерями скорости разработки ПО , так и  с возрастанием трудозатрат на поддержку внедренных процессов.

Рис. 52 Сравнение состава KPA в моделях CMM и CMMI .

Кроме того Assessment для CMMI будет значительно дороже, так как авторизованных SEI Lead Assessor'ов будет пока очень мало, и услуги эти  будут значительно более дорогие, чем при оценке на соответствие модели CMM.

Более того, многие зарубежные специалисты в области менеджмента качества, в том числе консультанты, довольно скептически отзываются о CMMI в контексте полезности для небольших и средних организаций (именно такие организации характерны для России и СНГ). Высказывается мнение, что через некоторое время SEI придется либо выпустить адаптированную SW-CMM v.2, либо произвести какие-то подобные шаги. Т.е. если рынок не примет модели, а такие предпосылки есть, то SEI надо будет адаптироваться к требованиям рынка.

Стандарты ISO 12207, 15504 и т. п. были разработаны Международной организацией стандартизации (ISO-International Organization for Standardization) для описания, соответственно, процессов обеспечения качества в организации, жизненного цикла программ и системы постоянного повышения качества процессов разработки ПО.

ISO 9001. Наиболее популярным, и ,особенно,  в Европе, является ISO 9001.

При этом методически, в полном соответствии с дисциплиной построения сложных систем, стандарт ISO 9001 предусматривает, с одной стороны, построение организационной системы "сверху вниз": от целей предприятия и его политики - к организационной структуре и формированию бизнес процессов, и с другой - итеративное развитие организационной системы через механизмы измерения и улучшения.

Упрощенно "качество", согласно серии стандартов ISO 9000, это ситуация, при которой потребители получают от производителя продукцию соответствующую их прямым требованиям и подспудным ожиданиям. Поэтому управление качеством, в соответствии с ISO 9000, предполагает применение т.н. "процессного подхода", когда моделируется и внедряется наиболее оптимальная цепь "преобразований-процессов", гарантирующая, что потребности потребителей воспринимаются производителем и воплощаются в любой продукт без искажений.

Многие организации -разработчики и заказчики ПО успешно используют эту широко известную серию стандартов ISO 9000. Новая версия стандартов этой серии вышла в 2000 году и уже содержит в себе такие понятия, как процессы и совершенствование процессов, заимствованные из модели СММ и ранее отсутствовавшие в предыдущих версиях ISO 9000. Следует, однако, заметить, что стандарты этой серии универсальны, не ориентированы на какую либо конкретную отрасль, не учитывает специфики IT-сферы и, в этом смысле, значительно уступают СММ. Кроме того, ISO 9000 не предполагает никаких градаций (уровней) соответствия и, тем самым, затрудняет определение "истинных" возможностей той или иной организации и, соответственно, - путей их дальнейшего равития.

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

COBIT (Control Objectives for Information and related Technology)-открытый стандарт, имеет свою нишу в общем комплексе стандартов, методик и руководств. Прежде всего, это стандарт управления и аудита ИТ. ITIL - библиотека лучшего практического опыта в части предоставления ИТ-услуг, а CobiT специализируется и на управлении и на аудите ИТ. Процессы ITIL, как и любые другие процессы, могут управляться и контролироваться стандартом CobiT.

Так же как и ITIL он построен на процессах, является открытым и независимым от конкретных производителей, платформ и технологий. Структурированность проявляется в COBIT очень сильно - 4 базовые группы (домена) содержат в себе 34 подгруппы, которые, в свою очередь состоят из 318 объектов контроля.

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

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

  Первая версия стандарта была выпущена в 1996 году Организацией аудита и контроля информационных систем (Information Systems Audit and Control Foundation, ISACF). Она включала в себя "Концептуальное ядро" (COBIT Framework), определяющее набор основополагающих принципов и понятий в области управления ИТ, описание "Задач управления" (Control Objectives) и "Руководство по аудиту" (Audit Guideline). Вторая версия COBIT была опубликована в 1998 году. Она содержала переработанную версию высокоуровневых и детальных "Задач управления", дополненных "Набором инструментов внедрения" (Implementation Tool Set). Третья редакция была выпущена уже Институтом управления ИТ (IT Governance Institute), учрежденным Ассоциацией аудита и контроля информационных систем (Information Systems Audit and Control Association, ISACA), совместно с ISACF с целью развития и популяризации принципов управления ИТ; он в настоящее время и является основным разработчиком COBIT. В третьей версии стандарта появилось "Руководство по менеджменту" (Management Guidelines) в основе которого лежит понятие "Система управления ИТ" (IT Governance).

IT CMM (The IT Service Capability Maturity Model - Модель Зрелости предоставления ИТ Услуг).

На базе Модели зрелости процессов разработки ПО в настоящее время разрабатывается модель зрелости для провайдеров ИТ-услуг. В декабре 2002 года опубликоавн черновик описания ее третьей ступени. Работа по созданию Модели ведется группой голландских организаций, координируемых Software Engineering Research Centre. Работа эта открыта для участия всех заинтересованных лиц и организаций.
В IT CMM ключевые процессы разделены на группы строже, чем в ITIL, при этом конкретные деятельности описаны в меньшей степени. Иными словами, если ITIL отвечает на вопрос "как", то IT CMM - на вопрос "что".
Если сравнивать между собой процессы, описанные в каждом из этих двух подходов, мы увидим, что в IT Service CMM гораздо больше внимания уделяется организационным моментам (в частности, процессы Organization Process Definition, Training Program, Intergroup Coordination не имеют аналогов в ITIL) и управлению собственно Услугами (в ITIL - один Service Level Management, в IT CMM - 3 процесса: Service Commitment Management, Service Tracking and Oversight, Subcontract Management). При этом ряд процессов, базовых для ITIL, в модели IT CMM объединены (в ITIL - Configuration и Change Management, в IT CMM - Configuration Management; процессу Service Delivery в IT CMM соответствуют три процесса ITIL - Release, Availability и IT Service Continuity Management).
Трудно оценивать перспективность использования этой модели к реальной организации управления ИТ, во всяком случае пока. Скорее всего, она, как и CobiT, более применима для оценки уровня предоставления услуг.

Microsoft , как известно, помимо собственно средств разработки ПО уже много лет развивает собственный вариант методологии управления жизненным циклом приложений - Microsoft Solutions Framework (MSF), представляющий собой набор описаний процессов, принципов и наиболее эффективных реализаций софтверных проектов

MSF (Microsoft Solutions Framework) - это концепция управления ИТ-проектами, тоже предложенная компанией Microsoft. MSF не привязан к каким-либо программными продуктам компании и представляет собой набор проверенных временем методик и лучших практик. Исходная версия MSF появилась в 1994 году в результате проекта по улучшению качества разработки именно в Microsoft. Нынешняя версия прошла долгий путь развития, ей присвоен номер 3.0. В отличие от большинства других методологий, MSF не ограничивается проблемами управления, а содержит конкретные технические рекомендации для разработчиков ПО.

MOF (Microsoft Operations Framework) -  это предложенный опять-же компанией Microsoft набор технических руководств, помогающих достигнуть требуемых от информационной системы уровней надежности, доступности, простоты в технической поддержке и управляемости. Рекомендации MOF касаются вопросов управления персоналом, процессами, технологиями и выработке стратегии управления в сложных распределенных гетерогенных IT-средах.

Действуя в этом направлении, Microsoft  объявила о начале более плотного сотрудничества с Software Engineering Institute (SEI), федеральным исследовательским центром, управляемым Университетом Carnegie Mellon при спонсорской поддержке министерства обороны США.

Результатом этого проекта должна стать возможность совместного применения MSF и модели управления процессами Capability Maturity ModelR Integration (CMMI)

PMBoK (Guide to the Project Management Body of Knowledge) - это проект Project Management Institute, вобравший в себя накопленные знания в области управления проектами {6}. Последняя версия документа вышла в 2000 году и тогда же получила статус стандарта американского института стандартизации ANSI (хотя стандарты ANSI и IEEE формально считаются американскими, большинство из них носит де-факто международный характер). Важной особенностью PMBoK является то, что он рассматривает управление проектами в общем смысле, без привязки к конкретным предметным областям, таким как информационные технологии, и потому не может применяться самостоятельно - ниже мы рассмотрим, какой эффект дает его использование совместно с ISO 9000.

RUP (IBM Rational Unified Process) - это методология процесса создания ПО, разработанный фирмой Rational  и содержащий детальные рекомендации по организации работы в крупных софтверных проектах, структурированию команды разработчиков, построению документооборота и т. д., вплоть до оформления исходных текстов программы на различных языках программирования.

Методология RUP позволяет объединить проектную команду, предоставляя в ее распоряжение проверенные мировой практикой лучшие подходы к разработке ИС. К ним относятся такие процессы жизненного цикла создания ПО, как управление проектами, бизнес-моделирование, управление требованиями, анализ и проектирование, тестирование и контроль изменений. Внедрение RUP в организации способствует выработке качественных внутрикорпоративных стандартов и повышению общей культуры разработки. RUP фокусирует внимание не на создании большого количества бумажных документов, а на развитии и применении визуальных моделей - семантически богатых представлений разрабатываемой ИС. RUP сосредотачивает внимание на разработке и дальнейшем развитии надежной и гибкой архитектуры, которая облегчает параллельную разработку, минимизирует необходимость изменений, увеличивает возможность многократного использования и надежность эксплуатации системы. Подобная архитектура применяется для планирования использования программных компонентов и управления их развитием. Методология RUP создавалась с прицелом на поддержку управления качеством в рамках требований SEI CMM/CMMI.

SWE BoK (официальное название - Guide to the Software Engineering Body of Knowledge) - совместный проект международных профессиональных обществ ACM и IEEE Computer Society. Основная идея проекта аналогична PMBoK и заключается в создании некоторого базового набора общепринятых знаний, необходимых любому профессиональному программисту. Такой набор не включает в себя материалы, относящиеся к другим областям (например, компьютерные науки или информационные системы), а также не содержит материалов, посвященных конкретным технологиям

UML (Unified Modeling Language)  - самый известный из существующих стандартов в области ИТ. С момента своего появления в 1994-96 гг. этот язык моделирования быстро набирал популярность и к сегодняшнему дня стал lingua franca в области проектирования информационных систем и бизнес-анализа. Можно с уверенностью сказать, что знание языка UML является необходимым условием для успешной работы в качестве ИТ-специалиста. Стандартизацией UML занимается влиятельный международный консорциум OMG (Object Management Group). Последняя стандартизованная версия UML имеет номер 1.5, одновременно ведется активная работа над принципиально новой версией 2.0. Существуют тысячи книг, описывающих процесс моделирования систем с помощью UML, так что изучение этой нотации и сопутствующих ей методов не является проблемой.

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

Особеность этого стандарта в том,  что он  сам базируется на стандартах серии ISO 9001 и ISO 12207 -см.  Рис 51,  а именно, он ,  кроме требований  ISO 9001 в себя включает набор требований и практик из стандартов ISO 12207 "Жизненный цикл ПО" и ISO 9000-3 "Руководство для внедрения ISO 9001:94 для разработки, установки и поддержки ПО" Преимуществами данной модели  является в первую очередь то, что данный стандарт представляет из себя достаточную систему  по которой можно не просто проверять, а самое главное действительно разрабатывать систему качества.
Так, же важным преимуществом является то, что разрабатывая систему качества по TickIT мы также построим полностью ISO 9001- совместимую компанию. К недостаткам TickIT можно отнести только недостаточное распространение данного стандарта и как следствие недостаточное его признание в мире.

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

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

Создание такой специальной схемы было вызвано особенностями индустрии ПО, которые требуют специальной подготовки аудиторов и интерпретации стандартов ISO 9000. Гибкая инфраструктура TickIT позволяет схеме следовать изменениям в этой весьма динамичной отрасли, тем самым обеспечивая постоянное совершенствование.

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

Теперь рассмотрим специальные методологии внедрения готовых ПС, требования к которым тоже содержатся в ISO 9001 .

AIM (Application Implementation Method ) - Методология "Внедрение приложений" направлена на управление проектами максимально быстрого и высококачественного внедрения приложений Oracle Applications. AIM регламентирует все основные стадии ведения проекта от этапа определения целей и стратегии до сопровождения новой системы.
       ASAP (Accelerated SAP ) - Методология "быстрого" внедрения ИС ERP-класса SAP R\3 разработанную ее произаводителем -корпорацией SAP AG с учетом лучших практик ее внедрения.

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

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

Эти методологии уже содержат все необходимые действия по обеспечению качества в соответствии с ISO 9001 и базируется на ЖЦ внедрения ПС ( SWP - Software Process -процессы разработки ПС ) в соответствии с RUP и ISO 12207.

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

А теперь, поняв кто, есть кто, снова посмотрим на Рис . 51.

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

На вопрос, гарантирует ли внедрение системы качества и успешная сертификация выпуск качественного продукта, следует ответить обескураживающее "нет". Подчеркивая, что ISO 9000 - "превосходная идея", Gartner Group рекомендует рассматривать сертификацию на ISO 9001:2000   только как исходную точку на пути к качеству .

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

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

• разработать и внедрить СМК по модели  ISO 9001:2000. (Ведь большинство компаний, которые сейчас находятся на 4-ом и 5-ом уровнях SW-CMM, сначала прошли через приведение своих процессов в соответствие модели ISO. Как показывает практика, это оптимальный вариант в плане управления развитием системы менеджмента качества и снижения рисков).

• Начать разрабатывать и внедрять ключевые процессы модели SW-CMM.

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

Рассмотрим, как соотносятся требования уже популярног стандарта ISO 9001:2000  с  общими свойствами становящейся все более популярной модели СММ  {3}-см.  Рис. 53.

Рис. 53 . Соответствие между общими свойствами СММ и элементами ISO 9001:2000

Каждый уровень СММ , как уже упоминалось,  характеризуется набором областей ключевых процессов (Key Process Areas -KPA).  Достижение всех целей в рамках KPA для определенного уровня СММ определяет соответствие организации данному уровню. Если хотя бы одна цель хотя бы одной KPA  для уровня СММ не достигнута, то организация не может соответствовать данному уровню CMM. KPA  можно разбить на три категории: управляющие, организационные и обеспечивающие (см. Рис. 54 ).

Рис. 54 . Категории ключевых процессов CMM

СММ не определяет все процессы, имеющие отношение к разработке программного обеспечения; в ней выделяются только те, которые необходимы для достижения уровня СММ, они и включаются в KPA . Каждая KPA  разбивается на 5 общих свойств (Common Features): Обязательство выполнить (Comment to perform); Способность выполнить (Ability to Perform); Выполняемые действия (Activities Performed); Измерение и анализ (Measurement and Analysis); Проверка реализации (Verifying Implementa­tion)

Общее свойство "Выполняемые действия" описывает действия, которые необходимо выполнить для достижения целей KPA , остальные четыре общих свойств описывают формальные факторы, делающие процесс частью организационной культуры. Полное выполнение всех ключевых приемов (key practice) из всех общих свойств обеспечивает достижение целей KPA . Ключевые приемы работы описывают, каким должен стать рабочий процесс (или элемент процесса, или часть инфраструктуры), но не определяют способ достижения (конкретные технологии или методики), хотя для некоторых приемов даются общие рекомендации. Для различных условий один и тот же результат может достигаться различными способами. Это скорее общие принципы работы, чем конкретные действия.

Последовательное выполнение общих свойств фактически реализует цикл улучшения процессов (См. выше- качество потенциала компании -КПК ), т.е. непрерывное улучшение бизнес-процессов -см . Рис. 55 .

Рис. 55 . Цикл непрерывного улучшения бизнес-процессов по модели CMM и ISO 9000:2000 .

Теперь неcколько практических  рекомендациий.

Желание получить сертификат соответствия в самые короткие сроки вынуждает консалтинговые компании и специалистов, занимающихся управлением качества, использовать гибкость и рамочность требований всех перечисленных высокоуровневых моделей в своих "корыстных" целях.
В результате такого форсирования событий у организации, напрмер ,получившей сертификат по ISO 9000:2000, определен только минимально-необходимый набор процессов для соответствия ISO 9001, а не все процессы, которые требуются компании для эффективного функционирования. Кроме того  - уровень детализации процессов не достаточен для четкого понимания того, что творится внутри процессов и кто, за какие задачи внутри процесса отвечает.
В лучшем случае через новые процедуры прошли лишь несколько тестовых проектов и через какое-то время становятся ясным необходимость их корректировки и дополнения. Часто, сразу после сертификации о построенной системе качества и процессах забывают до следующего надзорного аудита, забывая при этом и о затраченных финансовых ресурсах и энтузиазме сотрудников.
И действительно, когда выступаешь в роли независимого аудитора, очень сложно доказать, что принятый уровень детализации процесса явно не достаточен для эффективного функционирования системы качества компании. Но и доказать обратное за время, которое выделяется на аудит по ISO 9000, крайне сложно (этим очень успешно можно воспользоваться при оппонировании аудитору) . Практика показывает, что быстро построить эффективные процессы  даже 3-го уровня зрелости (также, по-хорошему, как и процессы на основе ISO 9000) невозможно.
Для того, чтобы этого добиться, недостаточно просто описать процессы с учетом требований выбранной модели. Самая главная сложность заключается в том, что необходимо перепроектировать культуру производства внутри организации. И сделать это волевым решением руководства невозможно. Именно поэтому подход, который определен в СMM, просто более жизнеспособен и реалистичен, чем в моделях ISO 9000 -см. Рис. 56.

Экспертная оценка степени покрытия ключевых процессов CMM требованиями ISO 9000:2000 , в соответствии с оценкой самих автров CMM {5}, показана на Рис . 56 .

Собственно оценка проводилась по двум координатам:

• степень обеспечиваемости ( в % ) соответствия процессов разработки (SWP) уровню зрелости в рамках CMM -"обеспечиваемость";

• степень возможности ( в % ) такой обеспечиваемости, которую дает ISO 9000:2000 - "возможность".

Как видно из приведенных данных {5}, требования ISO 9000:2000 создают реальную возможность для достижения даже верхнего (CMM Level 5) уровня зрелости SWP.

Однако в смысле уже обеспечения зрелости SWP хотя-бы третьего (CMM Level 3) уровня,  СМК  по модели  ISO 9000:2000 необходимо немного доработать- а именно разработать и внедрить  еще две организационные процедуры (Organization process definition and focus) и процедуру общего управления (Integrated software management), которые не представляют  сложности для любой ИТ-компании.

Но можно и нужно пойти дальше (CMM Level 4)  -например , в скобках показана авторская оценка (обеспечиваемости и возможности ), которая соответствует СМК по модели  ISO 9000:2000, в которой процесный ландшафт  СМК дополнен процедурами управления проектами в соответствии с требованиями PM BoK -  это может существенно увеличить зрелость еще таких SWP, как :

• Контроль за ходом выполнения проектов (Software project tracking and oversight);

• Планирование проектов  (Software project planning);

• Общее управление ПО ( Integrated software management);

• Управление процессами через количественные оценки( Quantitative process management).

Рис. 56 . Экспертная оценка степени покрытия ключевых процессов CMM требованиями ISO 9000:2000

Как видно из Рис. 56 , модель СММ по заложенным в ней принципам очень близка к СМК построенной по стандарту ИСО 9001:2000 и дополненной процессами управления проектами в соответствии с PM BoK.

Для того, чтобы не делать лишней работы при одновременных сертификации по ISO 9000 и последующей оценке по CMM , я рекомендую при определении производственных процессов включить ( а может и ими ограничиться !?) в их число все необходимые в модели CMM KPA. Таким образом компания одновременно:

• выполняет требования ISO 9001:2000  по внедрению процессного

подхода ;

• документирует все необходимые CMM процессы ( KPA);

• реализует при этом ряд таких важных требованиий  ISO 9001:2000  как :

• управление процессами на основе метрик ( Quantitative process management);

• управление Поставщиками на основе управления субконтрактами (Software subcontract management);

• анализ требований Потребителей на основе  управления требованиями  (Requirements management);

• управление человеческими ресурсами  на основе Программы обучения персонала ( Training program);

• управление коммуникациями  на основе создания формальных моделей организационных процессов ( Organization process definition);

• реализует механизм улучшения ( Plan-Dо-Check -Action) всех описанных процессов (SWP) посредством  последовательной реализации всех пяти Common Features .

Важно понять, что  и  СММ и ISO 9001:2000 являются всего лишь инструментами для непрерывного улучшения деятельности предприятия. Сертификация по стандарту ISO 9001:2000 и подтверждение сертификата должны способствовать росту качества процессов организации, где критерий оценки роста качества процессов - выход предприятия на новый уровень КПК {4}.

18. Вместо заключения

"Будующее за правильно

организованными Компаниями"

Джек Траут

Вот Вы и прочли все, что автор хотел Вам рассказать о подготовке к внедрению в Вашей Компании СМК.

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

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

Вы поняли,  что построение СМК - как раз очень сложный и многослойный  процесс а не просто подготовка необходимой документации !( см. Рис.  57и все вышесказанное ).

Рис.  57 Обзор необходимых работ при внедрении СМК

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

Поэтому мнение любого ИТ-специалиста по каждому  вопросу в процессе внедрения СМК может быть субъективно, а с точки зрения другого ИТ-специалиста - даже  необъективно! 

Автор не страдает манией величия и не приписывает себе роль создателя "истины в последней инстанции".

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

Давать советы дело, конечно  ,  неблагодарное, но опыт просто заставляет это сделать!

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

Постарайтесь найти именно таких- см. Рис 15.

И еще.

Никогда не доверяйте тем, кого плохо  понимаете.

Помните : "Кто ясно мыслит,  тот и ясно излагает"

19. На правах рекламы

"Стараться больше -не эффективно.

Старайтесь умнее"

Джек Траут

"Топ С Бизнес Интегратор"  выбирают,

и : "на это есть пять причин".

Причина 1. Мы сделаем то, чего вам не сделают другие

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

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

Причина 2. Мы умеем думать и решать конкретные  задачи

Главный актив нашей компании - профессионализм и интеллект наших ведущих консультантов - поэтому здесь  наш лозунг: "ТопС - лидер по качеству ИТ-услуг".

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

Наш сертификат, выданный TUV CERT на нашу собственную СМК, тому подтверждение.

Причина 3. У нас есть методология

Наше преимущество -  наличие постоянно растущей базы знаний именно  успешно выполненных ИТ -проектов.

Наша методология основана на многолетнем успешном опыте разработки и внедрения различных Информационных систем управления производством.

Мы находимся в курсе новых зарубежных исследований в области реинжениринга и оптимизации Бизнес-процессов.

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

В нашем активе успешный опыт применения  таких широкоизвестных методологий как:

• Описание процессов и последующее моделирование Бизнеса с использованием передовых CASE-средств ( ARIS, BPWin и т.п.);

• Внедрение  ИТ-систем  различного уровня и класса   для управления производством ( ERP -систем : Oracle ,BAAN , SAP , Axapta и т.п. );

• Система сбалансированных показателей деятельности (BSC);

• Требования стандарта ISO9001:2000 к процессному управлению и к системе управления качеством .

Причина 4. Мы учитываем российскую специфику

Наш опыт основан на проектах, проведенных именно в российских компаниях. Мы работаем на российский бизнес и всячески стремимся способствовать его подъему.

Причина 5. Мы продаем не часы, а результат

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

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

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

Придерживаясь международно принятой концепции "поддержки бизнеса заказчика (Partner business support)", мы всегда  предлагаем сумму технологий, точно настроенную на специфику организации заказчика: его стиль управления, этап жизненного цикла изделия, философию и стратегию предприятия, его приоритеты. Такой подход позволяет нам быстро находить гибкие и высокоэффективные решения.
Поэтому наши лозунги:  

• "Не Клиента под систему, а систему под клиента";

• "СМК должна работать на бизнес, а не за счет Бизнеса"

20. ПРИЛОЖЕНИЯ

"Человек, единственным инструментом которого

является молоток, во всем видит только гвозди"

Вильям Маслоу

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

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

Знания о бизнес-процессах компании, документируемые при помощи ARIS Toolset, не просто визуализируются в графическом виде, но и хранятся в базе данных. Таким образом обеспечивается непротиворечивость и многократное использование данных и моделей бизнес-процессов.

Вся необходимая для дальнейшего создания СМК документация  формируется в ARIS как отчет, т.е. описания процессов для Руководства по качеству создаются непосредственно из моделей цепочек добавленной стоимости, разработанных в ARIS Toolset. Методологические и рабочие инструкции создаются на базе eEPC-моделей.

Cамым удобным  для проекта разработки СМКи является описание  БП Компании  в формате расширенной событийно-ориентированной модели - eEPC (extended Event-driven Process Chain) { 2 }. Последовательность функций в рамках процесса  отображается в виде модели процесса, где для каждой функции определены начальные и конечные события. С помощью события описывается существующее состояние информационного объекта, которое позволяет осуществлять контроль или влиять на технологию протекания бизнес-процесса.

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

1. Реализация процессного похода при  описании БП в eEPC- модели ARIS

При создании моделей БП для реализации системного (или  процессного) подхода в Вашей Компании  , необходимо руководствоваться определенными требованиями в их описании. Набор таких требований содержится в международных стандартах серии ISO 9000:2000 {1}.

В соответствии с этими требованиями , модель БП должна включать следующую необходимую информацию.

1. Входы/поставщики процесса (process interface, document, technical term),

2. Выходы/клиенты процесса (process interface, document, technical term),

3. Ресурсы: персонал, оборудование, информация, среда (organization unit, application system и т.п.),

4. Технология выполнения процесса (event, function, operators),

5. Все этапы цикла управления (планирование, выполнение, контроль, анализ, принятие решений),

6. Контрольные точки для измерения показателей,

7. Возможные отклонения от нормального хода процесса,

8. Показатели процесса и данные удовлетворенности клиентов,

9. Участие руководителя (управление процессом).

Рассмотрим примеры представления этих требований в нотациях eEPC-модели.

Используемые в  дальнейших рисунках ( взятых из репозитария БП в среде ARIS ) обозначения приведены см.  на Рис. П-1.

Рис. П-1.

На Рис. П-2 показано описание БП, представляющее собой последовательность работ и событий .

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

Рис. П-2Описание работ и событий процесса - базовая eEPC-цепочка.

Описание входов и выходов БП

Пример базовой цепочки с описанием входа и выхода процесса показан на Рис. П-3

Рис. П-3 Описание входов и выходов процесса

Описание ресурсного окружения

Пример базовой цепочки с описанием ресурсного окружения показан на Рис. П-4

Рис. П-4 Описание ресурсного окружения работ

Описание технологий и участия руководителя

Пример базовой цепочки с описанием технологий выполнения процесса и описанием участия руководителя показан на Рис. П-5

Рис. П-5 Описание технологии и участия руководителя

Описание цикла управления процессом

Стандарт ISO 9000 указывает на необходимость описание цикла управления процессом в соответствии с так называемым циклом Деминга-Шухарта { 1 }- Plan-Do-Check-Action - см. выше Рис. 2

Пример базовой цепочки с описанием всего цикла управления процессом (планирование-  контроль-анализ - принятие решений ) показан на Рис. П- 6

Рис. П-6 Описание цикла управления процессом

Описание контрольных точек измерений и показателей процесса

Стандарт ISO 9000 указывает на необходимость разработки показателей достижения результатов процесса и описания контрольных точек в БП, где проводится их мониторинг { 1 } - пример такого описания показан на Рис. П-7

Рис. П-7 Описание контрольных точек измерений и показателей процесса

Описание отклонений от нормального хода процесса

Рассмотренный выше цикл управления процессом  , должен предусматривать корректирующие действия при возникновении возможных отклонений от нормального хода процесса {1} - пример такого описания показан на Рис. П-8.

.

Рис. П-8 Описание отклонений от нормального хода процесса

21. Использованные источники

1. ISO 9000:2000 .Система Менеджмента Качества . Требования.

2. "Инструментарий ARIS. Методы". Файл pdf. Поставляется вместе с демо-версией системы ARIS Toolset.

3. "Сила простоты", Джек Траут, Изд. Питер, 2003 г.

4. Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model  for Software, version 1.1. // CMU/SEI-93-TR-024, - Februaru, 1993.

5. Paulk M.C. A Comparison of ISO 9000 and SW-CMM  // CMU/SEI-94-TR-12, - July, 1994.

6. Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute.

7. Либерзон В. И. Основы управления проектами. М., 1997

8. "Оценка качества Програмных средств", В. Липаев, Синтег, 2001 г.

9. "Теория и практика реорганизации бизнес-процессов ", Калянов Г.Н., М.: СИНТЕГ, 2000г

10. "Как повысить эффективность службы управления персоналом в организации". К.Кравченко,  Управление персоналом ,N6, 2005 год.

Также на сайте:
Полезная модель EFQM: Профилактика системы управления
Что такое "мониторинг" и "измерение процесса"?

Новое на форуме

Наши рассылки

на Subscribe.Ru (описание):

на Mail.ru(описание):

О проекте

quality.eup.ru - один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.

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

Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.

Реклама на сайте