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

Глава одиннадцатая. Подводим итоги.

Из измерений получается количество, из количества – цифры, из цифр – сравнение, а из сравнений – победа. Сун Цу

– Друзья!

Сегодня настало время поговорить о том, что уже сейчас нам дала система качества!

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

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

– Они боятся, что это будет ограничивать их креативность?

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

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

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

Здесь еще раз напомню вам об основных наших показателях – это как раз отклонения от плана в себестоимости и длительности проекта!

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

Вот почему мы в обязательном порядке требуем наличие отчета о выполненном проекте!

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

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

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

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

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

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

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

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

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

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

– Да, вы правильно поняли, необходима просто исполнительская дисциплина, которой пока еще нет.

Ведь система качества – это только инструмент, а создают качество именно исполнители.

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

Вот откуда и выросло японское качество!

– Да, вы правы, в этом смысле Япония действительно «странная» страна. Но именно там кружки качества сделались тем средством, с помощью которого на каждом уровне производства снизу доверху коллективно прорабатываются и вносятся предложения по повышению качества продукции, процессов и ресурсов, что и требует система качества. А хотите – я вас снова приятно удивлю? Чем? А тем, что это все наш хорошо забытый опыт – правда, это помнит только старшее поколение – у нас, когда еще работали заводы, то на них помимо обязательных касс взаимопомощи всегда обязательно были и Бюро рационализаторских предложений и изобретательства (БРИЗ). Вот этот опыт они у нас и переняли, и теперь, по оценке экспертов, на восемьдесят процентов успехи японских фирм связаны именно с необычайно высокой активностью самих рабочих.

Поэтому и позволю себе перефразировать известный анекдот.

Вопрос: «Почему мы в России никак не можем внедрить японскую модель системы качества?».

Ответ: «Потому что у нас просто очень мало японцев!».

Так что, как там, у «нового» классика: «В чем сила, брат?». а сила опять только в человеческом факторе!

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

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

Россия.

Завод конца XXI века.

Кругом чистота, все стерильно, все блестит, все полностью автоматизировано.

Между станками идет робот:

– Г-де клю-ч на де-вят-над-цать? Г-де клю-ч на де-вят-над-цать? Навстречу ему другой робот:

– Г-де, г-де – в б-а-не!!!

Все роботы завода вместе хором:

– Ха-ха-ха!

– Да-да, действительно так, Россия – страна именно «недокументированных» возможностей… Шутка принята!

Ну очень в сегодняшнюю тему!

– На счет роботов?

– Не понял, поясните! Голос из зала:

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

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

Теперь он именно с нашей помощью эту возможность получил. И бездушие обрело формальное экономическое обоснование. Например, «General Motors» собирается уволить в ближайшие годы тридцать тысяч своих работников. Просто так выбросить на улицу. Потому что их КИС подсказывает: это позволит существенно улучшить ключевые показатели… Знаю одну компанию, в которой работают мои знакомые, там каждую неделю увольняют по несколько человек. Причем за неделю до увольнения всем сообщают: в вашем отделе будет уволено столько-то. Кого именно, решает опять-таки ERP-система, по принципу «соотношение приносимого дохода и затрат». Как люди доживают до следующего понедельника – не берусь описывать… И к этому мы с вами прикладываем не только руки, но и свои мозги. И по законам жанра наше творение рано или поздно должно погубить нас самих.

– Да уж чего – должно. Уже начинает! Я уже давно, именно как Директор по качеству, ощущаю этот процесс: наше продвинутое в MBA руководство «совершенно справедливо» отнесло Службу качества к центру затрат со всеми, сами понимаете, вытекающими последствиями, – затраты-то надо постоянно снижать!

– Да, совершенно справедливо, как во все той же басне Крылова «Свинья под дубом».

– Вам понравилось?

– Да-да, смешно, тогда на этой веселой ноте давайте и закончим.