Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
260 |
из-за того, что скакнуло напряжение в обычно стабильной сети питания станка — то это чистая случайность. Но если напряжение скачет постоянно, то и эту причину плохого качества можно устранить: поставить стабилизатор питания для станка, или заведомо выкидывать ту дешёвую заготовку, во время обработки которой произошёл сбой (а не пропускать её в выходную продукцию). Для того, чтобы поднять качество, нужно не столько просто его потребовать, объявив какие-то “жёсткие допуски”, сколько непрерывно искать источники проблем и устранять их, оставляя место только случайностям.
Шесть Сигм
Ещё одна практика, которая занята именно совершенствованием в части управления качеством через управление технологией работы и использование статистики — это Шесть Сигм (six sigma, http://en.wikipedia.org/wiki/Six_Sigma).
Название означает ситуацию, при которой статистически (все технологии работы с качеством опираются на статистику!) на 1 миллион изделий приходится 3.6 дефекта.
Как и любое другое совершенствование, практика шести сигм заключается в непрерывном прокручивании цикла DMAIC (Define, Measure, Analyze, Improve,
Control), а в части проектирования (DFSS, Design for Six Sigma) цикла DMDV (Define,
Measure, Analyze, Design, Verify).
Необязательно тут даже разбираться с содержанием всех этих циклов “обеспечения качества” (они удивительно похожи на вариации цикла Дёминга) — но нужно запомнить, что любое совершенствование циклично, по единичке качества за цикл.
Современный вариант шести сигм называют Lean Six Sigma (где lean переводится очень по-разному, вплоть до “бережливости” и обычно означает минимизацию работы в духе agile — если что-то можно не делать, то в lean это не делается).
В практике шести сигм можно найти целый набор различных практик, который в их приложении к какой-то технологии даёт её улучшение.
Критика Голдратта к шести сигмам была очень простой: он говорил о необходимости сначала находить ограничение (т.е. подходить сначала не с позиции “управления качеством”, а с логистической позиции “увеличения прохода работ через предпринятие”), и уже затем применять всю мощь практики шести сигма к найденному ограничению.
Тем самым нужно запомнить, что все эти “циклы совершенствования” обычно вложены друг в друга и взаимосвязаны (так, есть ещё цикл совершенствования процессов по “ступенькам зрелости”, стратегический цикл Бойда и т.д.).
Архитектура предпринятия
Основные альфы организационного и технологического решения предпринятия
Условно можно любое предпринятие вообразить выполняющим какие-то инженерные проекты. Предприятие что-то замышляет, проектирует, создаёт,
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
261 |
отлаживает, эксплуатирует (а не занимается фундаментальными исследованиями
— хотя и в этом случае можно представить себе жизненный цикл теории, появляющейся из гипотезы и проверочных экспериментов, но это будет большой натяжкой. Системные инженеры есть, системных учёных нет). В принципе, даже спасение душ в ходе прохождения каких-то тщательно спроектированных ритуалов в церкви — это ведь тоже вариант инженерной деятельности, привнесение в реальный мир из мира идей вполне материальных людей с определённым той или иной идеологией спасения образом мыслей!
В принципе, все такие инженерные деятельности можно также переформулировать как “сервисы”. Так, благотворительный фонд — это сервис для благотворителей, но вот бенефициары у него — получатели благ, они бенефициары, но не клиенты!
Если переформулировать систему-предпринятие в сервис, это оказывается чрезвычайно плодотворным. Предприятие, продуктом которого являются чугунные чушки мыслится совсем по-другому, чем предпринятие у которого сервис “поставка чугунных чушек”. Ибо сами чушки много менее разнообразный объект, нежели сервис “поставка” (в этом сервисе можно варьировать сроки поставки, распределение поставки во времени — чтобы она коррелировала с распределением потребления чушек по времени, включать “дополнительное обслуживание” типа логистики, в том числе погрузочно-разгрузочных операций и т.д.).
Как и любая другая система, предпринятие имеет определение и воплощение. Мы не говорим обычно, что это альфы “инженерного решения предпринятия”, это легко путается с инженерным решением целевой системы предпринятия. Скорее, мы говорим тут об альфах организационного и технологического решения предпринятия: как распределены ответственности и полномочия между людьми и группами людей (подразделениями) и какие практики поставлены (технологии развёрнуты) на предпринятии.
Подальфы определения предпринятия
Определение предпринятия имеет подальфы:
●Стратегии, описания целеполагания, бизнес-архитектуры (примерный аналог “требований” — описание системы в терминах её поведения как чёрного ящика)
●Архитектуры предпринятия (основные организационные и логистические решения)
●Неархитектурных организационных и логистических (операционных) решений.
Как и в случае и просто инженерной системы, описание системы-предпринятия для этих определений может быть, но может и не быть (так, описание может прозвучать на каком-то из совещаний менеджмента, или часть предпринятия как-то “сложилась” и никто не потрудился её описать, или только что описанное предпринятие быстро поменялось — ведь в предпринятии есть живые люди, это не железная или программная система, которая не может поменяться самопроизвольно!).
На определение предпринятия есть две полярных точки зрения:
●бесполезно его выражать в рабочих продуктах, ибо оно никогда-никогда не будет совпадать с реальностью. Люди несамотождественны в разные моменты времени! Просто описание предпринятия меняет его (ибо люди,
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
262 |
получив эти описания, немедленно меняют свою деятельность с учётом этой новой информации).
●Мы ничего не сможем изменить-поменять в предпринятии, пока мы его хоть как-то не определим (может быть, не детально, но в основных чертах — основные цели/требования, архитектуру).
Как обычно, определение предпринятия выражается в виде групп тематических описаний, которые в свою очередь состоят из моделей. Так, архитекторы предприятий признают стандарт ISO 42010 как относящийся и к архитектуре предпринятия (не только к программной или системной архитектуре).
Подальфы воплощения предпринятия
Определить/описать предпринятие — это описать его в терминах различных подальф его воплощения:
●деятельность (компоненты: услуги, сервисы, функции, роли, полномочия) — как устроено предпринятие, как оно работает (run time).
●Подразделения (как сгруппированы ресурсы — люди-сотрудники, здания, оборудование, материалы: модульное описание). Органиграмма и штатное описание, инвентарные ведомости для оборудования — это как раз модульное описание.
●Размещение (географическое нахождение ресурсов предпринятия): распределение подразделений (людей и оборудования) по зданиям, странам, рынкам и т.д.
●Многие другие интересные разным стейкхолдерам аспекты, ибо помним, что разные стейкхолдеры видят разные части в одном и том же объекте — части, удобные для использования в их деятельностях.
Виды практик описания деятельности
Деятельность предпринятия (”принципиальная схема”, “как оно работает”, компонентное описание) может быть описана самыми разными практиками описаний (viewpoints), делающими акценты на разные альфы в зависимости от того, для какой “деятельности над деятельностью” эти описания будут полезны:
●Технологии (way of working) — для управления технологиями (постановки практик, определения нужных компетенций, понимания связи с инженерией
— какие операции нужны, какие рабочие продукты, какие инструменты) нужны описания деятельности как состоящей из выполняемых практик — дисциплины (альфы), рабочие продукты и инструменты. Упор на то, с чем работаем (альфы и рабочие продукты), и только потом — какие с ними операции и в какой последовательности. Типичный пример — это описания ситуационной инженерии методов (в том числе по стандарту OMG Essence, но также и SPEM 2.0 и т.д.).
●Работы — упор на логистику: отслеживание выполнения работ ограниченными ресурсами предпринятия с целью максимизации прохода работ и контроля выполнения всех необходимых работ. Обычно это “процессные” и “проектные” описания.
●Команда — упор на организацию тех, кто выполняет работы, задаваемые практиками (полномочия, поручения, обещания и т.д.). Помним также, что
Системноинженерное мышление TechInvestLab, 2 апреля 2015 263
каждый член команды — это также и стейкхолдер, так что это описание “полномочия ролей” (компонент, а не заполняющих эти роли людей и подразделений).
Это, конечно, очень грубое деление — и нужно помнить, что и альфы тесно связаны друг с другом, и описания чаще всего гибридны. В работе http://www.ww.bptrends.com/publicationfiles/01-09-ART-%20Case%20Management-1- DeMan.%20doc—final.pdf эти основные виды моделирования называются соответственно:
●Artifact-based (упор на рабочие продукты — разные операции работают с какими-то рабочими продуктами),
●activity-based (процессно-ориентированные с предопределённой последовательностью операций),
●communication- (or conversation-) based: цель деятельности достигается как результат серии взаимодействий (коммуникаций, переговоров) участников деятельности.
Предпринятия-киборги, workflow
Когда-то считалось, что киборгами (cyborg = cybernetic organism) прежде всего станут люди: половина мозга и органов у них будут машинными, а половина останется “традиционными человечьими”. Но случилось так, что киборгами стали сначала организации: половина работы в них выполняется людьми (в том числе работы со знаниями и информацией), а половина уже выполняется инструментами (в том числе информационными системами).
Компьютер помнит сейчас планы работы из тысяч позиций, позволяет налаживать учёт конфигурации систем с миллионами компонент и модулей, ведёт расчёты графиков работы, хранит накопленные знания по прошлым проектам — без компьютеров современные организации просто не смогли бы выполнять сложные работы с участием тысяч людей и миллионов комплектующих, причём делать это дёшево и быстро.
Часто про деятельность, выполняемую людьми с использованием информационных систем, говорят “ход работ” (workflow — обратите внимание, что у нас работы, деньги, время “идут”, а в английском они “текут” — поэтому в русском языке труднее представить себе “потоковую” метафору предпринятия, необходимую для понимания операционного менеджента). В работе http://www.personal.psu.edu/axk41/BPM05-jerry-reprint.pdf для хода работ выделяют те же самые три “перспективы” (т.е. viewpoint), только называют их по-другому:
●для технологий информация-ориентированные (information-based, ибо речь идёт об информационных рабочих продуктах главным образом — отчётах, документах, формах и т.д.),
●для работ процесс-ориентированные (process based), а
●для команды — организационно-ориентированные (organization-based).
Как минимум, нужно помнить, что “процессный подход” (и его варианты “управление проектами”, “управление делами/case management”) абсолютно недостаточны для описания деятельности, для описания хода работ, для описания предпринятия в целом — есть и много других подходов, ставящих акценты и на альфы с рабочими продуктами (когда описывается не логистика, а содержание