Тихая революция 90-х
Тихая революция 90-х
Честно говоря, меня мало интересовали (и не интересуют сейчас) такие материи, как бизнес, маркетинг, менеджмент и иже с ними. Эти слова даже вызывают легкое раздражение: зачем они? Русские "дело, торговля и управление" ничем не хуже, хотя в них, конечно, нет очарования чего-то зарубежного и непостижимого. Иногда мне попадались упоминания о революции, произошедшей в сфере бизнеса развитых западных стран в 90-х годах. Они также не вызывали особого интереса, пока не встретилась хорошо переведенная (без "консалтингов") книга, рассказавшая о сути дела.
Читать было очень интересно. Возможно, эта параллель не совсем верна, но похоже, что в программировании такая революция произошла двадцатью годами раньше. Вспомните: кризис сложного программного обеспечения, а потом возникновение систематического, структурного и объектного программирования. Методологическое сходство поразительное. Правда, до прочтения книги не возникало и мысли о том, что принципы, известные из теории программирования и опробованные на собственном опыте, настолько широки и универсальны.
Какое отношение последующие несколько абзацев имеют к компьютерам и программированию, станет ясно не сразу. Признаться, я тоже не сразу понял, почему революции в организации бизнеса посвящена целая глава в монографии о технологии клиент-сервер. Спешу поделиться с вами открытием.
Все началось с того, что после Второй мировой войны экономика Японии оказалась совершенно разрушенной. Страна искала пути ее восстановления и стала рассматривать будущее как возможность построить производство лучшее, чем раньше, и сориентировать его на выпуск дешевой, но качественной продукции, конкурентоспособной на мировом рынке. В конце 50-х годов японская продукция была известна лишь в Азии, а в 60-х стала прокладывать себе путь в Европу и Америку, где поначалу пользовалась репутацией "дешевого барахла".
В настоящее время почти в любой области, где работают японские компании, их продукция считается образцом отличной конструкции и высочайшего качества, она дольше служит и лучше выглядит. Даже на рынке престижных автомобилей, на котором долгое время безраздельно царили американские и немецкие производители, японские Lexus, Infiniti и Acura стали вровень с Mercedes, BMW, Cadillac и Lincoln.
Сейчас потребители уже привыкли к недорогим изделиям, гарантийный срок службы которых распространяется на весь период физического существования. А вот в конце 80-х годов американские и европейские компании были шокированы тем, что японцы стали вытеснять их с международных рынков. Западные компании спешно изучили восточный опыт и начали перестраиваться.
Японцы изобрели способ всестороннего управления качеством (ВУК или TQM, от Total Quality Management). Сейчас кое-кто считает идею ВУК устаревшей, отдавая предпочтение перепроектированию деловых процессов (ПДП или BPR, от Business Processes Reengeneering). Однако ПДП можно назвать ВУК на новый лад, поскольку в основе обоих лежат одни и те же принципы.
Если у вас нет своей большой компьютерной фирмы, то вам все равно будет интересно, как японцы сумели улучшить качество своей электроники и при этом сократить затраты против прежнего. Если вы программист и подступаетесь к теме разработки АСУ, то вы, наверное, успели обнаружить, что специальная литература посвящена, во-первых, принципам организации и управления, во-вторых, методам перепроектирования деловых процессов, а в-третьих, технологии CASE. По этому пути и пойдем.
Классическая исторически сложившаяся структура организации, состоящей из многих людей, способной управлять большими ресурсами и осуществлять сложные производственные (и иные) процессы, построена по жесткой иерархической схеме. Изображенная на бумаге, она напоминает пирамиду. На самом верху пирамиды находится малочисленное руководство, принимающее основные решения, осуществляющее стратегическое планирование и преобразование стратегических планов в менее крупные планы действий.
Кроме того, руководство разрабатывает и утверждает правила, согласно которым должна вестись работа. Такие правила называют и бизнес-правилами, и процедурами фирмы, но по существу их следует назвать политикой предприятия. Когда программист пишет складскую программу, которая отказывается выдавать накладную на отпуск товара, записи о котором нет в базе данных, он программирует бизнес-правило. Право, эти импортные словеса загадочны только на вид, а по сути не многим сложнее грабель.
Ниже, в средней части пирамиды, находится так называемое среднее звено управления. Управленцы среднего звена заняты координацией использования ресурсов предприятия, в особенности дефицитных. Благодаря их согласующим и организующим действиям предприятие ритмично работает без потрясений, вызываемых исчерпанием финансовых или сырьевых запасов, отказами основного оборудования и так далее. Другая, не менее важная, роль среднего звена управленцев: они проводят в жизнь то, что мы назвали политикой предприятия. И это понятно: не директору же сидеть за компьютером, выписывая накладные.
В самом низу пирамиды размещаются конторские служащие и рабочие - самый многочисленный отряд персонала предприятия. Они принимают заказы, производят продукцию - словом, обеспечивают работу организации в целом, выполняя свои четко обрисованные конкретные задачи.
Способ иерархического строения и организации изобретен человечеством в незапамятные времена. Столь же давно он проверен на практике и зарекомендовал себя с наилучшей стороны. За примером этого не нужно далеко ходить: так устроены и армия, и церковь, и государство. Таким образом человечество издревле справлялось с решением задач необозримой сложности и объема.
Лежащий в основе иерархического способа управления принцип прост и ясен, по крайней мере программистам. Они практически ежедневно представляют крупную задачу в виде нескольких меньших модулей, которые уже можно обозреть. Последние в свою очередь подразделяются и так далее - пока все не окажется сведенным на деле к элементарно простым процедурам или объектам. Классическая схема нисходящей разработки.
Наверное, самое глубокое и последовательное выражение этот подход получил в организации конвейерного производства. Рядовые работники производственных и сборочных конвейеров выполняют настолько простые монотонно повторяющиеся операции, что их возможно заменить автоматами, что и происходит на передовых автомобильных заводах, которые нам изредка показывает телевидение.
Кстати, CASE-технология - прямой аналог автоматизированного завода. Сравните: в управленческой иерархии работают живые люди, обеспечивающие функционирование завода, а продукцию производят роботы. В случае CASE программист описывает и макетирует, но не разрабатывает кода программы, который генерируется автоматически.
Что ж, эта система работала и будет работать в обозримом будущем. Пора соотнести ее с проблемой качества продукции, с обсуждения которой был начат разговор. Когда происходит проверка качества изделия? Естественно, как только оно сойдет с конвейера. То есть тогда, когда что-либо изменить уже невозможно, а остается констатировать факт выпуска дефектного продукта. И это для программистской братии не новость. Еще Эшер Дийкстра говорил, что тестирование программы способно эффективно доказать наличие ошибок в программе, но никак не их отсутствие.
Как же тогда улучшить качество изделий и программ? Вопрос, как появляется брак и почему "в любой законченной программе есть хотя бы одна ошибка", настолько интересен, что не жаль усилий для поиска ответа. Представляю вам один из возможных ответов. Думаю, автор (или авторы) этой идеи родом из Японии. Мне же она знакома в изложении Дэвида Васкевича.
Конвейер задуман, чтобы как возможно снизить личную ответственность рабочего, играющего роль автомата. Будем считать, что он допускает какую-либо погрешность в своей операции один раз на тысячу. Для человека это хороший показатель, а за качество деталей он по определению не отвечает.
Предположим, среди деталей и комплектующих, используемых при сборке трактора (телевизора, компьютера и т.п.), каждая отдельно взятая деталь может содержать дефект с вероятностью 1 на 100,000. Эта ничтожно малая вероятность приводит к тому, что в сложном изделии из двух-трех тысяч деталей, наподобие трактора, в каждом тридцатом-пятидесятом экземпляре практически всегда окажется дефектный элемент.
В том случае, когда на конвейере стоит около сотни человек, выполняющих по 20-30 элементарных операций по сборке трактора из двух-трех тысяч деталей, логично ожидать, что в каждом готовом изделии будет два-три дефекта сборки. Это несмотря на то, что вероятность совершения ошибки каждым работником за время сборки одного трактора равна 20-30 х 0.001, то есть 2-3 процента. Такова арифметика вероятностей. Как же в таком мире выпускать продукцию и обеспечивать качество? Над этим вопросом бились американские и европейские экспортеры, когда японцы начали вытеснять их с рынков. О том же за десятилетие или два до этого задумались разработчики громадных программных комплексов, которые создавались годами, стоили миллионы (долларов), но так и не смогли заработать из-за массы ошибок в коде.
Ответ, как производить лучшую продукцию, состоит из двух частей: не тянуть с контролем качества "до последнего" и перенести внимание с задач на процессы. Чтобы с этим разобраться, вернемся к аналогии сборочного конвейера.
Человек на конвейере не может знать, что изготовленная им деталь содержит дефект, так как делает только ее и не заботится о качестве конечного продукта, поскольку за него не отвечает. Технология конвейера подразумевает, что все детали изготавливаются обособленно, а потом сборщики, тоже независимо один от другого, соединяют их воедино. Это тот самый случай, когда в игру вступают суммы вероятностей, обсуждавшийся выше. Контроль за качеством отложен на самый последний момент, когда ничего нельзя изменить и остается лишь зафиксировать наличие брака, дотянут "до последнего".
Теперь представим себе завод, где тракторы собираются по многомодульной схеме. Пусть трактор имеет 10 агрегатов, каждый из которых состоит из 20-30 узлов, собираемых, в свою очередь, из 10 деталей. Число деталей то же, что и в предыдущем примере, вся разница в способе монтажа. Пусть узлы каждого вида собирают один-два человека, то есть та же сотня рабочих.
Собрав свой узел, рабочий проверяет его работоспособность сразу же по окончании сборки. Проверяет - и отбраковывает дефектные детали, не допустив их попадания на другие стадии производственного цикла. Точно так же поступают люди, собирающие агрегаты из узлов. Собранный агрегат немедленно проходит испытания, и выявленные дефектные узлы возвращаются на соответствующую стадию производства. В результате собранный из готовых агрегатов трактор фактически не нуждается в итоговой проверке качества - он безусловно работает, так как слагающие его агрегаты проверены, как и составляющие их узлы. Вероятность, что на последнем этапе работник не справится с монтажом 10 агрегатов, ничтожно мала, а главное - таковой она и останется.
Выходит, что идеальные сборочные единицы (не детали!) получить все-таки можно, введя промежуточный контроль качества. При наличии множества ступеней промежуточного контроля вероятности начинают работать, так сказать, в другую сторону. Теперь они не складываются, а умножаются. Если вероятность пропуска дефекта человеком составляет одну тысячную, то вероятность того, что дефект "преодолеет" две ступени контроля равна одной миллионной.
Скажите, пожалуйста, вам ничто не напомнило о принципах структурного программирования и о Паскале? Ведь типизация данных служит той же цели -обнаружению ошибок на более ранней стадии технологического процесса изготовления программы. А в языках программирования, допускающих разбиение программы на самостоятельные модули и раздельную компиляцию, этот принцип прослеживается еще четче.
Итак, способ, как избежать "посмертного" контроля качества, заменив его поистине всеобъемлющим и действенным, ясен. Причем же здесь процессы? Дело в том, что логика конвейера разделяет один сложный процесс производства на простые задачи, упрощая его. Однако простота задачи не является гарантией идеальности результата. Упрощение подразумевает разбиение до такой степени простоты, что не о чем думать и не за что отвечать. Если же не думать и не отвечать, то о каком качестве речь? ВУК предполагает разбиение общего сложного процесса на множество простых, каждый из которых гарантирует качество. С одной стороны, элементарный процесс должен быть мал, чтобы легко поддаваться управлению и охвату. В этом и состоит смысл разбиения. С другой стороны, есть критерий, согласно которому процесс нельзя дробить до бесконечности. Он должен остаться достаточно сложным, чтобы являться логически завершенной стадией более крупного процесса и можно было говорить о его цели и смысле.
В самом деле, если существует самый незначительный процесс, устремленный к своей маленькой цели, становится возможным ответ, достигнута ли цель, что и есть контроль качества. О вырванной из общего контекста элементарной операции, лишенной самостоятельного смысла, такого не скажешь. Примененная к программированию эта идея звучит даже лучше. Скажем, "писать процедуры, имеющие четко определенный смысл, чтобы их было можно осмысленно отладить".
Принципы ВУК прямо противоположны организации конвейера. Первый из них гласит, что каждый работник отвечает за производство и проверку в рамках осуществляемого им процесса. Вместо бездумного выполнения бессодержательной задачи работник управляет своим процессом, имеющим смысл и результат, который может и должен быть оценен.
Второй принцип говорит, что работника нужно снабдить всеми инструментами и оборудованием, необходимыми для такой проверки и оценки. Вместо того чтобы в случае чего докладывать и ожидать распоряжения сверху, обученный и обеспеченный сведениями работник самостоятельно принимает решения в меру своей ответственности.
Как видите, такой человек совсем не похож на "неодушевленный винтик" конвейера. Кстати, кое-что из сказанного могло напомнить вам о бригадном подряде, хозрасчете, комплексных механизированных бригадах и строителях-"злобинцах". Ведь все это у нас было - в советское время и на советский лад.
В очередной раз перепрыгивая из мира материального производства в мир компьютерный, хочу вас спросить: разве все, только что описанное, не соответствует чистейшему подходу объектного программирования? Возьмите любой учебник и убедитесь сами, как проводится стратегия "разделяй и властвуй" и за счет чего обеспечивается надежность сложных программ.
Наконец, наверное стоит привести мнение, достаточно широко распространенное в среде специалистов по управлению. Оно заключается в том, что сферу управления допустимо понимать точь-в-точь как производство, только перерабатывающее информацию и выпускающее информацию. Особенно любят это сравнение компьютерные фирмы и информационные службы, что вовсе неудивительно.
Поэтому к управлению полностью применимы все рассуждения относительно качества конечного продукта и декомпозиции процессов. Словом, изобретенная в Японии система всестороннего управления качеством с равным успехом применима как к организации производства, так и к организации управления производством. Кстати, интересно, что это изобретение примерно совпало по времени с разработкой первых структурных и объектных языков программирования.
Внедрение ВУК в сферу управления как раз и есть предмет перепроектирования деловых процессов (ПДП). Теперь, когда мне стало известно содержание и значение тихой революции 90-х годов, я с уважением отношусь к сокращениям ВУК и ПДП, то есть TQM (Total Quality Management) и BPR (Business Process Reengeneering), так же как к структурному и объектному программированию, но говорить "реинжиниринг бизнес-процессов" или "постановка регулярного менеджмента" - все равно не буду.
Евгений Щербатюк
Честно говоря, меня мало интересовали (и не интересуют сейчас) такие материи, как бизнес, маркетинг, менеджмент и иже с ними. Эти слова даже вызывают легкое раздражение: зачем они? Русские "дело, торговля и управление" ничем не хуже, хотя в них, конечно, нет очарования чего-то зарубежного и непостижимого. Иногда мне попадались упоминания о революции, произошедшей в сфере бизнеса развитых западных стран в 90-х годах. Они также не вызывали особого интереса, пока не встретилась хорошо переведенная (без "консалтингов") книга, рассказавшая о сути дела.
Читать было очень интересно. Возможно, эта параллель не совсем верна, но похоже, что в программировании такая революция произошла двадцатью годами раньше. Вспомните: кризис сложного программного обеспечения, а потом возникновение систематического, структурного и объектного программирования. Методологическое сходство поразительное. Правда, до прочтения книги не возникало и мысли о том, что принципы, известные из теории программирования и опробованные на собственном опыте, настолько широки и универсальны.
Какое отношение последующие несколько абзацев имеют к компьютерам и программированию, станет ясно не сразу. Признаться, я тоже не сразу понял, почему революции в организации бизнеса посвящена целая глава в монографии о технологии клиент-сервер. Спешу поделиться с вами открытием.
Все началось с того, что после Второй мировой войны экономика Японии оказалась совершенно разрушенной. Страна искала пути ее восстановления и стала рассматривать будущее как возможность построить производство лучшее, чем раньше, и сориентировать его на выпуск дешевой, но качественной продукции, конкурентоспособной на мировом рынке. В конце 50-х годов японская продукция была известна лишь в Азии, а в 60-х стала прокладывать себе путь в Европу и Америку, где поначалу пользовалась репутацией "дешевого барахла".
В настоящее время почти в любой области, где работают японские компании, их продукция считается образцом отличной конструкции и высочайшего качества, она дольше служит и лучше выглядит. Даже на рынке престижных автомобилей, на котором долгое время безраздельно царили американские и немецкие производители, японские Lexus, Infiniti и Acura стали вровень с Mercedes, BMW, Cadillac и Lincoln.
Сейчас потребители уже привыкли к недорогим изделиям, гарантийный срок службы которых распространяется на весь период физического существования. А вот в конце 80-х годов американские и европейские компании были шокированы тем, что японцы стали вытеснять их с международных рынков. Западные компании спешно изучили восточный опыт и начали перестраиваться.
Японцы изобрели способ всестороннего управления качеством (ВУК или TQM, от Total Quality Management). Сейчас кое-кто считает идею ВУК устаревшей, отдавая предпочтение перепроектированию деловых процессов (ПДП или BPR, от Business Processes Reengeneering). Однако ПДП можно назвать ВУК на новый лад, поскольку в основе обоих лежат одни и те же принципы.
Если у вас нет своей большой компьютерной фирмы, то вам все равно будет интересно, как японцы сумели улучшить качество своей электроники и при этом сократить затраты против прежнего. Если вы программист и подступаетесь к теме разработки АСУ, то вы, наверное, успели обнаружить, что специальная литература посвящена, во-первых, принципам организации и управления, во-вторых, методам перепроектирования деловых процессов, а в-третьих, технологии CASE. По этому пути и пойдем.
Классическая исторически сложившаяся структура организации, состоящей из многих людей, способной управлять большими ресурсами и осуществлять сложные производственные (и иные) процессы, построена по жесткой иерархической схеме. Изображенная на бумаге, она напоминает пирамиду. На самом верху пирамиды находится малочисленное руководство, принимающее основные решения, осуществляющее стратегическое планирование и преобразование стратегических планов в менее крупные планы действий.
Кроме того, руководство разрабатывает и утверждает правила, согласно которым должна вестись работа. Такие правила называют и бизнес-правилами, и процедурами фирмы, но по существу их следует назвать политикой предприятия. Когда программист пишет складскую программу, которая отказывается выдавать накладную на отпуск товара, записи о котором нет в базе данных, он программирует бизнес-правило. Право, эти импортные словеса загадочны только на вид, а по сути не многим сложнее грабель.
Ниже, в средней части пирамиды, находится так называемое среднее звено управления. Управленцы среднего звена заняты координацией использования ресурсов предприятия, в особенности дефицитных. Благодаря их согласующим и организующим действиям предприятие ритмично работает без потрясений, вызываемых исчерпанием финансовых или сырьевых запасов, отказами основного оборудования и так далее. Другая, не менее важная, роль среднего звена управленцев: они проводят в жизнь то, что мы назвали политикой предприятия. И это понятно: не директору же сидеть за компьютером, выписывая накладные.
В самом низу пирамиды размещаются конторские служащие и рабочие - самый многочисленный отряд персонала предприятия. Они принимают заказы, производят продукцию - словом, обеспечивают работу организации в целом, выполняя свои четко обрисованные конкретные задачи.
Способ иерархического строения и организации изобретен человечеством в незапамятные времена. Столь же давно он проверен на практике и зарекомендовал себя с наилучшей стороны. За примером этого не нужно далеко ходить: так устроены и армия, и церковь, и государство. Таким образом человечество издревле справлялось с решением задач необозримой сложности и объема.
Лежащий в основе иерархического способа управления принцип прост и ясен, по крайней мере программистам. Они практически ежедневно представляют крупную задачу в виде нескольких меньших модулей, которые уже можно обозреть. Последние в свою очередь подразделяются и так далее - пока все не окажется сведенным на деле к элементарно простым процедурам или объектам. Классическая схема нисходящей разработки.
Наверное, самое глубокое и последовательное выражение этот подход получил в организации конвейерного производства. Рядовые работники производственных и сборочных конвейеров выполняют настолько простые монотонно повторяющиеся операции, что их возможно заменить автоматами, что и происходит на передовых автомобильных заводах, которые нам изредка показывает телевидение.
Кстати, CASE-технология - прямой аналог автоматизированного завода. Сравните: в управленческой иерархии работают живые люди, обеспечивающие функционирование завода, а продукцию производят роботы. В случае CASE программист описывает и макетирует, но не разрабатывает кода программы, который генерируется автоматически.
Что ж, эта система работала и будет работать в обозримом будущем. Пора соотнести ее с проблемой качества продукции, с обсуждения которой был начат разговор. Когда происходит проверка качества изделия? Естественно, как только оно сойдет с конвейера. То есть тогда, когда что-либо изменить уже невозможно, а остается констатировать факт выпуска дефектного продукта. И это для программистской братии не новость. Еще Эшер Дийкстра говорил, что тестирование программы способно эффективно доказать наличие ошибок в программе, но никак не их отсутствие.
Как же тогда улучшить качество изделий и программ? Вопрос, как появляется брак и почему "в любой законченной программе есть хотя бы одна ошибка", настолько интересен, что не жаль усилий для поиска ответа. Представляю вам один из возможных ответов. Думаю, автор (или авторы) этой идеи родом из Японии. Мне же она знакома в изложении Дэвида Васкевича.
Конвейер задуман, чтобы как возможно снизить личную ответственность рабочего, играющего роль автомата. Будем считать, что он допускает какую-либо погрешность в своей операции один раз на тысячу. Для человека это хороший показатель, а за качество деталей он по определению не отвечает.
Предположим, среди деталей и комплектующих, используемых при сборке трактора (телевизора, компьютера и т.п.), каждая отдельно взятая деталь может содержать дефект с вероятностью 1 на 100,000. Эта ничтожно малая вероятность приводит к тому, что в сложном изделии из двух-трех тысяч деталей, наподобие трактора, в каждом тридцатом-пятидесятом экземпляре практически всегда окажется дефектный элемент.
В том случае, когда на конвейере стоит около сотни человек, выполняющих по 20-30 элементарных операций по сборке трактора из двух-трех тысяч деталей, логично ожидать, что в каждом готовом изделии будет два-три дефекта сборки. Это несмотря на то, что вероятность совершения ошибки каждым работником за время сборки одного трактора равна 20-30 х 0.001, то есть 2-3 процента. Такова арифметика вероятностей. Как же в таком мире выпускать продукцию и обеспечивать качество? Над этим вопросом бились американские и европейские экспортеры, когда японцы начали вытеснять их с рынков. О том же за десятилетие или два до этого задумались разработчики громадных программных комплексов, которые создавались годами, стоили миллионы (долларов), но так и не смогли заработать из-за массы ошибок в коде.
Ответ, как производить лучшую продукцию, состоит из двух частей: не тянуть с контролем качества "до последнего" и перенести внимание с задач на процессы. Чтобы с этим разобраться, вернемся к аналогии сборочного конвейера.
Человек на конвейере не может знать, что изготовленная им деталь содержит дефект, так как делает только ее и не заботится о качестве конечного продукта, поскольку за него не отвечает. Технология конвейера подразумевает, что все детали изготавливаются обособленно, а потом сборщики, тоже независимо один от другого, соединяют их воедино. Это тот самый случай, когда в игру вступают суммы вероятностей, обсуждавшийся выше. Контроль за качеством отложен на самый последний момент, когда ничего нельзя изменить и остается лишь зафиксировать наличие брака, дотянут "до последнего".
Теперь представим себе завод, где тракторы собираются по многомодульной схеме. Пусть трактор имеет 10 агрегатов, каждый из которых состоит из 20-30 узлов, собираемых, в свою очередь, из 10 деталей. Число деталей то же, что и в предыдущем примере, вся разница в способе монтажа. Пусть узлы каждого вида собирают один-два человека, то есть та же сотня рабочих.
Собрав свой узел, рабочий проверяет его работоспособность сразу же по окончании сборки. Проверяет - и отбраковывает дефектные детали, не допустив их попадания на другие стадии производственного цикла. Точно так же поступают люди, собирающие агрегаты из узлов. Собранный агрегат немедленно проходит испытания, и выявленные дефектные узлы возвращаются на соответствующую стадию производства. В результате собранный из готовых агрегатов трактор фактически не нуждается в итоговой проверке качества - он безусловно работает, так как слагающие его агрегаты проверены, как и составляющие их узлы. Вероятность, что на последнем этапе работник не справится с монтажом 10 агрегатов, ничтожно мала, а главное - таковой она и останется.
Выходит, что идеальные сборочные единицы (не детали!) получить все-таки можно, введя промежуточный контроль качества. При наличии множества ступеней промежуточного контроля вероятности начинают работать, так сказать, в другую сторону. Теперь они не складываются, а умножаются. Если вероятность пропуска дефекта человеком составляет одну тысячную, то вероятность того, что дефект "преодолеет" две ступени контроля равна одной миллионной.
Скажите, пожалуйста, вам ничто не напомнило о принципах структурного программирования и о Паскале? Ведь типизация данных служит той же цели -обнаружению ошибок на более ранней стадии технологического процесса изготовления программы. А в языках программирования, допускающих разбиение программы на самостоятельные модули и раздельную компиляцию, этот принцип прослеживается еще четче.
Итак, способ, как избежать "посмертного" контроля качества, заменив его поистине всеобъемлющим и действенным, ясен. Причем же здесь процессы? Дело в том, что логика конвейера разделяет один сложный процесс производства на простые задачи, упрощая его. Однако простота задачи не является гарантией идеальности результата. Упрощение подразумевает разбиение до такой степени простоты, что не о чем думать и не за что отвечать. Если же не думать и не отвечать, то о каком качестве речь? ВУК предполагает разбиение общего сложного процесса на множество простых, каждый из которых гарантирует качество. С одной стороны, элементарный процесс должен быть мал, чтобы легко поддаваться управлению и охвату. В этом и состоит смысл разбиения. С другой стороны, есть критерий, согласно которому процесс нельзя дробить до бесконечности. Он должен остаться достаточно сложным, чтобы являться логически завершенной стадией более крупного процесса и можно было говорить о его цели и смысле.
В самом деле, если существует самый незначительный процесс, устремленный к своей маленькой цели, становится возможным ответ, достигнута ли цель, что и есть контроль качества. О вырванной из общего контекста элементарной операции, лишенной самостоятельного смысла, такого не скажешь. Примененная к программированию эта идея звучит даже лучше. Скажем, "писать процедуры, имеющие четко определенный смысл, чтобы их было можно осмысленно отладить".
Принципы ВУК прямо противоположны организации конвейера. Первый из них гласит, что каждый работник отвечает за производство и проверку в рамках осуществляемого им процесса. Вместо бездумного выполнения бессодержательной задачи работник управляет своим процессом, имеющим смысл и результат, который может и должен быть оценен.
Второй принцип говорит, что работника нужно снабдить всеми инструментами и оборудованием, необходимыми для такой проверки и оценки. Вместо того чтобы в случае чего докладывать и ожидать распоряжения сверху, обученный и обеспеченный сведениями работник самостоятельно принимает решения в меру своей ответственности.
Как видите, такой человек совсем не похож на "неодушевленный винтик" конвейера. Кстати, кое-что из сказанного могло напомнить вам о бригадном подряде, хозрасчете, комплексных механизированных бригадах и строителях-"злобинцах". Ведь все это у нас было - в советское время и на советский лад.
В очередной раз перепрыгивая из мира материального производства в мир компьютерный, хочу вас спросить: разве все, только что описанное, не соответствует чистейшему подходу объектного программирования? Возьмите любой учебник и убедитесь сами, как проводится стратегия "разделяй и властвуй" и за счет чего обеспечивается надежность сложных программ.
Наконец, наверное стоит привести мнение, достаточно широко распространенное в среде специалистов по управлению. Оно заключается в том, что сферу управления допустимо понимать точь-в-точь как производство, только перерабатывающее информацию и выпускающее информацию. Особенно любят это сравнение компьютерные фирмы и информационные службы, что вовсе неудивительно.
Поэтому к управлению полностью применимы все рассуждения относительно качества конечного продукта и декомпозиции процессов. Словом, изобретенная в Японии система всестороннего управления качеством с равным успехом применима как к организации производства, так и к организации управления производством. Кстати, интересно, что это изобретение примерно совпало по времени с разработкой первых структурных и объектных языков программирования.
Внедрение ВУК в сферу управления как раз и есть предмет перепроектирования деловых процессов (ПДП). Теперь, когда мне стало известно содержание и значение тихой революции 90-х годов, я с уважением отношусь к сокращениям ВУК и ПДП, то есть TQM (Total Quality Management) и BPR (Business Process Reengeneering), так же как к структурному и объектному программированию, но говорить "реинжиниринг бизнес-процессов" или "постановка регулярного менеджмента" - все равно не буду.
Евгений Щербатюк
Компьютерная газета. Статья была опубликована в номере 24 за 1997 год в рубрике разное :: бизнес
