что может делать процесс
процесс
Предмет изучения исторических наук это процесс возникновения, развития и упадка общественно-исторических формаций. | Превращение гусеницы в бабочку — медленный процесс.
Снимок показал, что в лёгких у больного есть очаг воспалительного процесса.
Составляя производственное задание, не забудьте указать в нём этапы технологического процесса.
Гражданский процесс. | Уголовный процесс.
Муж возбудил бракоразводный процесс по факту неверности жены. | Процесс над преступником получил широкую огласку.
Новые идеи рождались у друзей прямо в процессе работы.
Полезное
Смотреть что такое «процесс» в других словарях:
процесс — См. действие, дело, спор вести процесс. Словарь русских синонимов и сходных по смыслу выражений. под. ред. Н. Абрамова, М.: Русские словари, 1999. процесс движение, течение, ход; дело, тяжба, слушание, суд, судебное дело; работа, эксплуатация,… … Словарь синонимов
ПРОЦЕСС — (лат., processus прохождение). 1) судебный ход дела, гражданского или уголовного. 2) в химии: различные операции, от которых изменяется состав тела, напр. перегонка, растворение. Словарь иностранных слов, вошедших в состав русского языка. Чудинов … Словарь иностранных слов русского языка
ПРОЦЕСС — ПРОЦЕСС, процесса, муж. (лат. processus). 1. Ход, развитие какого нибудь явления; последовательная закономерная смена состояний в развитии чего нибудь. «Процесс ликвидации феодализма и развития капитализма является в то же время процессом… … Толковый словарь Ушакова
Процесс 50-ти — «Процесс пятидесяти» («Процесс москвичей», Суд над участниками «Всероссийской социально революционной организации», официальное название: «Дело о разных лицах, обвиняемых в государственном преступлении по составлению противозаконнаго сообщества и … Википедия
Процесс 50-ти — («Процесс 50 ти»,) процесс «москвичей», суд над участниками «Всероссийской социально революционной организации» (См. Всероссийская социально революционная организация). Проходил в Особом присутствии Правительствующего сената (Петербург)… … Большая советская энциклопедия
процесс — а, м. procès m. нем. Prozess <, лат. processus движение вперед. 1. Разбор судебного дела; само судебное дело. Процесс о наследстве. Бракоразводный процесс. БАС 1. И потом кинувшись к Сент Жону, статскому секретарию, хотел таким же образом… … Исторический словарь галлицизмов русского языка
процесс — Совокупность взаимосвязанных ресурсов и деятельности, которая преобразует входящие элементы в выходящие. [МУ 64 01 001 2002] процесс Структурированная совокупность действий, спроектированная для достижения конкретной цели. Процесс преобразует… … Справочник технического переводчика
Процесс 21-го — («Процесс 21 го») последний крупный судебный процесс над революционными народниками. Проходил в Петербургском военно окружном суде 26 мая (7 июня) 5 (17) июня 1887. Главные обвиняемые Г. А. Лопатин (по имени которого процесс иногда… … Большая советская энциклопедия
ПРОЦЕСС — ПРОЦЕСС категория философского дискурса, характеризующая совокупность необратимых, взаимосвязанных, длительных изменений, как спонтанных, так и управляемых, как самоорганизованных, так и организуемых, результатом которых является некое… … Философская энциклопедия
Процесс — [process] (в кибернетике) последовательная смена состояний, стадий изменения (развития) системы или иного объекта (См. также Преобразование). Различают процессы: вещественные (например, преобразование сырья в готовый продукт в производстве) и… … Экономико-математический словарь
Operating Systems: Three Easy Pieces. Part 2: Абстракция: Процесс (перевод)
Привет, Хабр! Хочу представить вашему вниманию серию статей-переводов одной интересной на мой взгляд литературы — OSTEP. В этом материале рассматривается достаточно глубоко работа unix-подобных операционных систем, а именно — работа с процессами, различными планировщиками, памятью и прочиими подобными компонентами, которые составляют современную ОС. Оригинал всех материалов вы можете посмотреть вот тут. Прошу учесть, что перевод выполнен непрофессионально (достаточно вольно), но надеюсь общий смысл я сохранил.
Рассмотрим наиболее фундаментальную абстракцию, которую ОС предоставляет пользователям: процесс. Определение процесса довольно-таки просто — это работающая программа. Программа сама по себе является безжизненной вещью, располагающейся на диске — это набор инструкций и возможно каких-то статических данных, ожидающих момента запуска. Именно ОС берет эти байты и запускает их, преобразую программу во что-то полезное.
Чаще всего пользователи хотят запускать более одной программы одновременно, например вы можете запустить на вашем ноутбуке браузер, игру, медиаплеер, текстовый редактор и тому подобное. Фактически типичная система может запускать десятки и сотни процессов одновременно. Этот факт делает систему более простой в использовании, вам никогда не приходится беспокоиться о том, свободен ли CPU, вы просто запускаете программы.
Отсюда вытекает проблема: как обеспечить иллюзию множества CPU? Как ОС создать иллюзию практически бесконечного количества CPU, даже если у вас всего один физический CPU?
ОС создает эту иллюзию посредством виртуализации CPU. Запуская один процесс, затем останавливая его, запуская другой процесс и так далее, ОС может поддерживать иллюзию того, что существует множество виртуальных CPU, хотя фактически это будет один или несколько физических процессоров. Такая техника называется разделение ресурсов CPU по времени. Эта техника позволяет пользователям запускать столько одновременных процессов, сколько они пожелают. Ценою такого решения является производительность – поскольку если CPU делят несколько процессов, каждый процесс будет обрабатываться медленнее.
Для воплощения виртуализации CPU, а особенно для того чтобы делать это хорошо, ОС нуждается и в низкоуровневой и в высокоуровневой поддержке. Низкоуровневая поддержка называется механизмами — это низкоуровневые методы или протоколы, которые реализуют нужную часть функционала. Пример такого функционала — контекстное переключение, которое дает ОС возможность останавливать одну программу и запускать на процессоре другую программу. Такое разделение по времени реализовано во всех современных ОС.
На вершине этих механизмов располагается некоторая логика, заложенная в ОС, в форме “политик”. Политика — это некоторый алгоритм принятия решения операционной системой. Такие политики, например, решают, какую программу надо запускать (из списка команд) в первую очередь. Так, например, данную задачу решит политика, называющаяся планировщик (scheduling policy) и при выборе решения будет руководствоваться такими данными как: история запуска (какая программа была запущена дольше всех за последнюю минут), какую нагрузку осуществляет данный процесс (какие типы программ были запущены), метрики производительности (оптимизирована ли система для интерактивного взаимодействия или для пропускной способности) и так далее.
Абстракция: процесс
Абстракция работающей программы, выполняемая операционной системой это то, что мы называем процесс. Как уже было сказано ранее процесс – это просто работающая программа, в любой моментальный промежуток времени. Программа с помощью которой мы можем получить суммарную информацию с различных ресурсов системы, и к которым обращается или которые эта программа затрагивает в процессе своего выполнения.
Для понимания составляющих процесса нужно понимать состояния системы: что программа может считывать или изменять во время своей работы. В любой момент времени нужно понимать, какие элементы системы важны для выполнения программы.
Одним из очевидных элементов состояния системы, которые включает в себя процесс — это память. Инструкции располагаются в памяти. Данные, которые программа читает или пишет также, располагаются в памяти. Таким образом, память, которую процесс может адресовать (так называемое адресное пространство) является частью процесса.
Также частью состояния системы являются регистры. Множество инструкций направлено на то, чтобы изменить значение регистров или прочитать их значение и таким образом регистры тоже становятся важной частью работы процесса.
Следует отметить, что состояние машины формируется также из некоторых специальных регистров. Например, IP — instruction pointer — указатель на инструкцию, которую программа исполняет в текущий момент. Еще есть stack pointer и связанный с ним frame pointer, которые используются для управления: параметрами функций, локальными переменными и адресами возврата.
Наконец, программы часто обращаются к ПЗУ (постоянному запоминающему устройству). Такая информация о “I/O” (вводе-выводе) должна включать в себя список файлов, открытых процессом в данный момент.
Process API
Для того чтобы улучшить понимания работы процесса изучим примеры системных вызовов, которые должны быть включены в любой интерфейс операционной системы. Эти API в том или ином виде доступны на любой ОС.
Создание процесса: детали
Одна из интересных вещей — как же именно программы трансформируются в процессы. Особенно, как ОС поднимает и запускает программу. Как конкретно создается процесс.
В первую очередь ОС должна загрузить код программы и статические данные в память (в адресное пространство процесса). Программы обычно располагаются на диске или твердотельном накопителе в некотором исполняемом формате. Таким образом, процесс загрузки программы и статических данных в память требует от ОС возможности прочитать эти байты с диска и расположить их где-то в памяти.
В ранних ОС процесс загрузки выполнялся нетерпеливо (eagerly), то есть это значит что код загружался в память целиком до того как программа запускалась. Современные ОС делают это лениво (lazily), то есть загружая кусочки кода или данных только тогда, когда они требуются программе во время ее выполнения.
После того как код и статические данные загружены в память ОС нужно выполнить еще несколько вещей перед тем как запустить процесс. Некоторое количество памяти должно быть выделено под стек. Программы используют стек для локальных переменных, параметров функций и адресов возврата. ОС выделяет эту память и отдает ее процессу. Стек также может выделяться с некоторыми аргументами, конкретно она заполняет параметры функции main(), например массивом argc и argv.
Операционная система может также выделять некоторое количество памяти под кучу (heap) программы. Куча используется программами для явно запрашиваемых динамически выделенных данных. Программы запрашивают это пространство, вызывая функцию malloc() и явно очищает, вызывая функцию free(). Куча нужна для таких структур данных как: связанные листы, таблицы хэшей, деревья и другие. По началу под кучу выделяется маленькое количество памяти, но со временем в процессе работы программы куча может запросить большее количество памяти, через библиотечный API вызов malloc(). Операционная система вовлечена в процесс выделения большего количества памяти для того, чтобы помочь в удовлетворении этих вызовов.
Операционная система также будет выполнять задачи инициализации, в частности те, которые относятся к вводу-выводу. Например, в системах UNIX каждый процесс по умолчанию имеет 3 открытых файловых дескриптора, для стандартного потока ввода, вывода и ошибок. Эти дескрипторы позволяют программам считывать ввод из терминала, а также выводить информацию на экран.
Таким образом, загружая код и статические данные в память, создавая и инициализируя стек, а также выполняя другую работу, относящуюся к выполнению задач ввода-вывода, ОС подготавливает площадку для выполнения процесса. В конце концов, остается последняя задача: запустить на исполнение программу через ее точку ввода, называемую функцией main(). Переходя к выполнению функции main(), ОС передает управление CPU вновь созданному процессу, таким образом, программа начинает исполняться.
Состояние процесса
Теперь, когда у нас есть некоторое понимание, что такое процесс и как он создается, перечислим состояния процесса, в которых он может находиться. В самой простой форме процесс может находиться в одном из этих состояний:
● Running. В запущенном состоянии процесс выполняется на процессоре. Это значит, что происходит выполнение инструкций.
● Ready. В состоянии готовности процесс готов запуститься, но по каким-то причинам ОС не исполняет его в заданный момент времени.
● Blocked. В заблокированном состоянии процесс выполняет какие-то операции, которые не дают ему быть готовым к исполнению до тех пор, пока не произойдет какое-либо событие. Один из обычных примеров — когда процесс инициализирует операцию IO, он становится заблокированным и таким образом какой-то другой процесс может использовать процессор.
Представить себе эти состояния можно в виде графа. Как мы можем видеть на картинке, состояние процесса может меняться между RUNNING и READY на усмотрение ОС. Когда состояние процесса меняется с READY, на RUNNING это означает, что процесс был запланирован. В обратную сторону — снят с планировки. В момент, когда процесс становится BLOCKED, например, инициализирую операцию IO, ОС будет держать его в этом состоянии до наступления некоторого события, например завершение IO. в этот момент переход в состояние READY и возможно моментально в состояние RUNNING, если так решит ОС.
Давайте взглянем на пример того, как два процесса проходят через эти состояния. Для начала представим, что оба процесса запущены, и каждый использует только CPU. В этом случае, их состояния будут выглядеть следующим образом.
В следующем примере первый процесс через некоторое время работы запрашивает IO и переходит в состояние BLOCKED, предоставляя другому процессу возможность запуска (РИС 1.4). ОС видит, что процесс 0 не использует CPU и запускает процесс 1. Во время выполнения процесса 1 — IO завершается и статус процесса 0 меняется на READY. Наконец процесс 1 завершился, а по его окончание процесс 0 запускается, исполняется и заканчивает свою работу.
Структура данных
ОС сама является программой, и также как и любая другая программа имеет некоторые ключевые структуры данных, которые отслеживают разнообразные релевантные куски информации. Для отслеживания состояния каждого процесса в ОС будет поддерживаться некоторый process list для всех процессов в состоянии READY и некоторую дополнительную информацию для отслеживания процессов, которые выполняются в текущий момент. Также, ОС должна отслеживать и заблокированные процессы. После завершения IO, ОС обязана пробудить нужный процесс и перевести его в состояние готовности к запуску.
Так, например, ОС должна сохранить состояние регистров процессора. В момент остановки процесса состояние регистров сохраняется в адресном пространстве процесса, а в момент продолжения его работы — восстановить значения регистров и таким образом продолжить выполнения этого процесса.
Кроме состояний ready, blocked, running существуют еще некоторые другие состояния. Иногда в момент создания процесс может иметь состояние INIT. Наконец процесс может быть помещен состояние FINAL, когда он уже завершился, но информация о нем еще не вычищена. В UNIX системах такое состояние называется процесс-зомби. Это состояние полезно для случаев когда родительский процесс хочет узнать код возврата потомка, например, обычно 0 сигнализирует об успешном завершении, а 1 об ошибочном, однако программисты могут делать дополнительные коды вывода, сигнализируя о разных проблемах. При завершении процесс-родитель делает последний системный вызов, например wait(), чтобы дождаться завершения работы процесса-потомка и просигнализировать ОС о том, что можно очистить любые данные, связанные с завершенным процессом.
Процессы: что это такое и зачем?
Что такое процессы и какую проблему решает процессный подход
До книжки вот все никак руки не доходят, а высказаться по этому вопросу хочется. Реальность, увы, такова, что материалов по процессному подходу море, да только толку от этого… Причем, надо понимать, что процессы процессам рознь: тот же Инталев активно разрабатывает эту тему, но исключительно в направлении управления финансами и бухучета. Если мы посмотрим книги того же В.В. Репина, то и там о специфических процессах менеджмента качества говорится как-то вскользь, особенно, в последней вышедшей книге. Он, как, впрочем, и многие авторы, пишущие на темы процессного подхода, основной упор делает на производственные процессы, которые, по сложившейся у нас практике, называют часто «бизнес-процессами». Кстати, всем, кто всерьез интересуется вопросами процессного подхода, порекомендовал бы сходить на сайт Сергея Рубцова и прочитать ту часть его монографии, которая касается процессов. Написано сложным языком, не совсем можно соглашаться, но прочесть, честное слово, стоит. При соответствующем настрое, может навести на полезные мысли.
Попробуем разобраться в задумке.
Чтобы удостовериться, что мы на правильном пути, попробуем предположить обратное: процесс – это конкретная деятельность, дающая на выходе конкретный (осязаемый) результат. Возникает забавная ситуация: вот, например, предприятие, изготавливающее гайки. Производство одной гайки – это процесс? Допустим. Но тогда, если предприятие хочет перейти к процессному управлению, следует ли ему выделять столько процессов, сколько производится гаек? Разум, что называется, протестует против такого вывода. Хорошо, может тогда предприятию надо выделить столько процессов, сколько видов гаек производится? Решение как-то тоже, надо сказать, восторга не вызывает.
Стоп. Так можно долго бродить в потемках. Надо пойти с другого конца: а зачем нам нужны процессы? Может ответ на этот вопрос поможет продвинуться в понимании, что это такое?
Я глубоко убежден, что любой подход, любой инструмент, который изобретает человечество, есть – в той или иной степени – решение какой-то проблемы. Интересно, какие проблемы вызвали к жизни процессный подход? Попробуем с этим разобраться.
Скажем, 50 лет назад о процессном управлении еще не говорили. У того же Янга в его книге «Системное управление организацией» упоминаются процессы, но несколько в ином смысле, и идеи процессного управления там еще не просматриваются. И в книге А. Фейгенбаума «Контроль качества продукции», вышедшей на русском языке в 1986 году, мы еще не встретим упоминания о процессах в известном нам смысле. Но с другой стороны, в предисловии научного редактора к русскому изданию 1997 года известной книги Хаммера и Чампи «Реинжениринг корпорации. Манифест революции в бизнесе» указано, что «Тему реинжениринга специалисты по менеджменту начали разрабатывать уже во второй половине 80-х годов, однако прорыв в исследованиях этого феномена принято ассоциировать со статьей М. Хаммера «Реинжениринг традиционных методов работы: не автоматизируйте их, а отвергайте», опубликованной в четвертом номере «Harvard Business Review» за 1990 г». Стало быть, возникновение идеи процессного подхода к управлению можно отнести к 80-м годам прошлого века.
Логика подхода понятна. Предприятие выпускает продукцию, в создании которой принимают участие многие подразделения и участки предприятия. Каждое подразделение и участок имеют свои цели и интересы, в общем случае, мало синхронизированные между собой. Каждое подразделение и участок искренне старается работать лучше и достигать поставленных целей, но есть одна проблема: никто не может сказать, а насколько это старание «работает» на конечный продукт. У этой болезни есть название: локальная оптимизация. И именно ее призван излечить процессный подход.
Меня зовут Андрей, у меня небольшая фирма по сборке компьютеров. Три человека: один (Антон) собирает, один (Алексей) устанавливает программы, третий (Аркадий) тестирует готовый компьютер и проверяет, все ли ПО установлено. Перед каждым сотрудником поставлена цель: максимальная производительность. Но, откровенно говоря, я уже замучался: вроде, парни стараются вовсю, а мы толком не успеваем ничего, сроки поставок срываются, хотя весь офис забит собранными компами, готовыми для установки программ и тестирования. Я уже подумываю о том, не взять ли в аренду пустующую соседнюю квартиру, чтобы организовать там склад. Мы договорились, что за перевыполнение задания каждый получает бонус и так получается, что этот бонус постоянно выше у Антона, а Алексей с Аркадием получают меньше, хотя сил тратят больше. Я чувствую, назревает конфликт. Д и мне, откровенно говоря, бонусы-то платить особо не с чего: мы ведь компьютеров-то больше не продаем, дополнительных денег не появляется. Странная какая-то ситуация складывается: все стараются, о клиентах заботимся: вот ввели новую услугу – сборка по заказу, а доход не увеличивается, а если уж совсем начистоту, то дела-то все хуже идут.
В чем проблема Андрея? Почему при таком напряжении всех сил результат (и эффективность) оказываются не на высоте?
Думаю, что особого секрета здесь ни для кого нет: всему виною ошибочность основного принципа управления, попытка Андрея управлять своей небольшой фирмой как тремя разными и независимыми частями. Но ведь продукт, который он поставляет клиентам, один. Почему бы не попробовать организовать своего рода «конвейер» от начала сборки компьютера до самой последней операции и действия всех сотрудников не подчинить одной цели: максимальной производительности на выходе «конвейера»? А координатором общей деятельности назначить Антона, т.к. у него явная тяга и способности к организации.
А теперь небольшое отступление.
Обратите внимание, что для предприятия, с точки зрения его организационного построения, при переходе к процессам, ничего не меняется: оно по-прежнему остается набором подразделений. Но с точки зрения управления происходят кардинальные перемены: объектами целевого управления теперь становятся не подразделения, а процессы.
Андрей провел у себя реорганизацию: он всех ребят объединил в одну бригаду, которую возглавил Антон. Цель у бригады одна: постоянный рост дохода. Бонус выплачивается всей бригаде от процента роста.
Это что ж получается – мы «всего-то» изменили объекты управления (процессы вместо подразделений) и получили результат? В этом нет ничего удивительного. Вот пример. Большое стадо овец, пастух пытается загнать его в загон, направляя «управленческое воздействие» на каждую овцу в отдельности. Промучившись с час и совершенно выбившись из сил, он-таки решил поставленную задачу. А по соседству опытный товарищ действовал иначе: нашел в стаде барана и направляя «управленческое воздействие» на него, загнал барана в загон. Через несколько минут все стадо было в загоне. Так что правильно выбранный объект управления – это очень важно.
Итак, с точки зрения системного подхода процессное управление – это смена точки зрения на состав элементов системы: вместо представления «система = совокупность подразделений», мы используем представление «система = совокупность процессов».
Вот и выходит, что разработчики из ИСО под процессом понимают то «совокупность видов деятельности» (т.е. некое обобщенное представление), то саму эту деятельность (которая имеет реальный результат). Им хорошо: написали и давай продвигать, а нам-то делать…
Известно, что всякий метод имеет ограничения и универсальных методов не существует (что бы ни утверждал тов. Машкин). Каковы же ограничения процессного подхода?
Они могут быть установлены по следующим соображениям.
Процесс – это в свою очередь система, составляющими частями которой являются те самые «виды деятельности», о которых речь шла в начале. Определение процесса в ИСО 9000 никакой информации, полезной для установления границ процесса в рамках организации, не дает, т.е. процесс, строго говоря, может быть как «сквозным», т.е. входом в него будет вход в организацию, а выходом – выход из организации, так и локальным, включающим в себя лишь небольшой участок деятельности.
Преимущество процессного подхода основано на том, что единым объектом управления становится вся деятельность, направленная на получение конечного (т.е. поставляемого потребителю) результата. А это с неизбежностью ведет нас к выводу, что чем крупнее процессы (чем они ближе к «сквозным»), тем преимущества процессного подхода проявляются ярче. И наоборот, чем сильнее мы дробим процессы, тем больше сводим на нет преимущества метода. Ведь мы помним, что наша задача – избавиться от локальной оптимизации.
Таким образом, на текущий момент мы можем констатировать, что
1) процессный подход – это средство повышения эффективности деятельности за счет устранения локальной оптимизации,
2) процессный подход – это изменение объектов управления,
3) процессы (объекты управления) должны быть «сквозными» и в небольшом количестве. Дробление процессов противоречит задаче процессного подхода.
С вопросом, зачем нужен процессный подход, думаю, разобрались. Теперь вернемся к тому, с чего начали: как быть предприятию, выпускающему гайки, сколько процессов ему выделять и по какому принципу. Надеюсь, что ответ на этот вопрос уже очевиден: один процесс (если рассматривать только изготовление гаек и абстрагировавшись от другой необходимой деятельности). Предприятию надо устранить локальную оптимизацию в производстве гаек, что может быть достигнуто выделением процесса «Производство гайки» и управлением им, как системой.
Построение процессных систем
Я уже как-то ворчал по поводу того, что кого ни спроси, все строят процессные модели. Само по себе это дело, конечно, хорошее, но вот что смущает: большинство из разработчиков не смогло мне ответить на два-три простых вопроса: кто потребитель разрабатываемой модели и какие решения он будет принимать на основе ее, в чем цель построения модели и чью точку зрения она отражает.
Если Вы в данный момент занимаетесь построением процессной модели, но тоже не можете ответить на эти простые вопросы, то остановитесь, пока не поздно, ибо Ваш проект обречен на неудачу. Под неудачей я понимаю то, что все нарисованное Вами, возможно, и будет утверждено разными высокими визами, но после этого благополучно ляжет на полку, откуда будет доставаться исключительно в волнующие дни аудитов СМК. В том случае, если для Вашего проекта такая (или подобная) судьба – удача, то дальше можете не читать. 🙂
С теми же, кто хотел бы, чтобы созданные им документы активно использовались, будем разбираться дальше.
Начнем с того, что зададимся вопросом: а для чего, для решения каких задач нам могут потребоваться модели процессов?
На мой взгляд, таких задач всего две:
1) регламентирование деятельности и
2) анализ деятельности.
В первом случае нам надо разработать такую модель, которая бы служила образцом, эталоном, нормой – говоря иными словами, описывала бы систему процессов так, как она должна выглядеть. Т.е. решение задачи регламентирования деятельности прямиком ведет нас к созданию модели To Be.
И теперь уже совсем нетрудно догадаться, что вторая задача связана с построением модели As Is. И в самом деле: если мы хотим провести анализ деятельности, то нам надо эту деятельность каким-то образом описать, отобразить так, как она реально выполняется.
Небольшое отступление. Очень часто можно встретить следующую рекомендуемую последовательность действий (взято из материалов Betec, выложенных Романом 17 марта под заголовком «Бизнес-процессы и оргструктура»):
Выходит, что если уж мы запланировали анализ модели «как есть», то он может быть выполнен только после разработки модели «как должно быть», а иначе при анализе с чем сравнивать-то? Т.е. последовательность должна выглядеть (как минимум) так:
А теперь вернемся к нашим баранам, то бишь задачам моделирования As Is и To Be. Поговорим о технологии решения этих задач, ведь традиционно считается, что она и в том, и в другом случае одинакова. И это ошибка! Причем ошибка дорогостоящая!
Надеюсь, что у читающего уже смутно забрезжила мысль, что не зря я все это рассказываю и что технологии построения двух типов моделей различны. Так оно и есть.
Итак, все та же модель To Be. Суть ее в том, чтобы представить деятельность так, она должна выполняться, т.е. некое конечное целевое состояние. По сути, это требования к построению процесса. А кто выставляет такого рода требования? Руководитель. А с технической точки зрения – специалист в этой области. А кто у нас специалист в этой области, кто может сказать, как должны быть построены процессы, необходимые системе менеджмента качества? Правильно – менеджер качества. Что для него является при этом путеводной нитью? Правильно, все те знания по построению систем менеджмента вообще и конкретной (например, по модели той же ИСО 9001 ), в частности. Именно менеджера качества учили (учили? 🙂 ), как правильно строить СМК, как должны быть выстроены процессы (элементы системы) и именно в этом знании его ценность для организации. Специалисты других профилей там уже есть.
Таким образом, менеджер качества сам, никого не спрашивая, разрабатывает нормативную модель To Be, основываясь на общесистемных требованиях и требованиях выбранной организацией модели менеджмента качества. Ведь никого, скажем, не удивляет, что главбух выстраивает в организации процессы бухучета и ни с кем при этом не советуется. Попробуйте-ка ему предложить свою точку зрения на то, как эти процессы должны выглядеть… Реакцию, думаю, нетрудно представить. Так вот, процессы СМК – это точно такая же единоличная епархия менеджера качества! Ему эта епархия дана в управление и он здесь полновластный хозяин, он устанавливает законы деятельности в рамках СМК.
Итак, что мы имеем? Менеджер качества рисует «эталонный маршрут», но никто не гарантирует, что организация ему следует. Для понимания, насколько мы придерживаемся запланированного «маршрута», необходимо отразить наш текущий путь, реальное выполнение процессов, если уйти от аллегории.
И вот здесь мы пойдем туда, где эта деятельность выполняется и начнем спрашивать, как она выполняется и строить модель As Is. А дальше, как уже все догадались, будет анализ этой модели, сравнение ее с моделью To Be. А у меня вопрос: какое условие необходимо выполнить, чтобы анализ был успешен? Ответ: модели To Be и As Is должны быть сравнимыми, т.е. принципиально допускать такое сравнение. Как это сделать? А вот это тема для домашнего размышления 🙂
А кстати, навскидку, когда нам могут понадобиться модели As Is и анализ, о котором идет речь? Тут большой загадки, действительно, нет: конечно, при внутреннем аудите СМК. Если на нашей модели To Be обозначена деятельность, а на практике (в модели As Is) ее нет, то вот вам и несоответствие. Например, по нашей модели процессов СМК владелец процесса должен анализировать и оценивать результативность процесса, а в жизни этого нет – управление происходит исключительно «по событию».
Похоже, что пора подводить итоги, а то лекция плавно перерастет в книгу.