Comments 33
шутка про кооператив "Озеро"
Сомневаюсь, что в таком виде это можно продать председателю кооператива.
Продукты (цели) описаны очень обобщенно - непонятно, какие конкретно задачи решаются.
Хотя, для минсельхоза, возможно, зайдёт...
описаны очень обобщенно
В статье сказано, что избегал детализации и углубления, чтобы "не выплеснуть" идею (концепцию). Для примера не столь важны формулировки (короткие или длинные) целей или продуктов, названий процессов (можно добавить поле "подробное описание").
Когда всю модель ЕА можно хранить только в черепной коробке (председателя или иного), т.е. она небольшая (скорее - крохотная, - как в примере), то значимость ЕА - не высокая. Если линейно возрастает масштаб организации, то сложность ЕА уже в геометрической прогрессии.
Часто заказчиками ЕА являются не руководители организации, а собственники.
для минсельхоза, возможно, зайдёт...
В целом - "да", предложенный подход применим и для архитектур масштаба федеральных организаций (правительств, государств) и полагаю, что не хуже FEAF, Методологий архитектуры предприятия для органа власти (MAGENTA) и т.п. Технически придется сделать несколько связанных альбомов visio к общему excel-файлу из-за значительно возросшего объема для такой архитектуры.
Для Захмановского фреймворка я встречал только пример описания баскетбольной команды. https://www.researchgate.net/publication/251201368_The_Zachman_Framework_Populated_with_Baseball_Models
Я не большой знаток бейсбола (хотя фирменная бейсбольная бита от лаборатории Касперского висит на стенке), но всерьез воспринять Table 3. A Zachman Framework Populated with Baseball Models - как ЕА, не смог. Полагаю, что по этой же причине на этот пример не ссылаются и в https://en.wikipedia.org/wiki/Zachman_Framework
Хотя я и играл в бейсбол на позиции питчера в университетской команде, отвечу как нынешний корп.архитектор -- любые модели субъективны и отражают чьи-то взгляды и профессиональные деформации. В данной статье 20 страниц объяснений и подводок к результатам, поэтому я воспринимаю это лишь как "их мнение", с которым можно и нужно спорить.
-- любые модели субъективны и отражают чьи-то взгляды и профессиональные деформации.
Не совсем согласен: есть религиозные модели (библия, коран и т.п.) - где наличие ошибок несущественно, а есть модель атома Резерфорда, модель самолета, в которой если будет критическая ошибка, то он просто не взлетит. Пока дисциплина Enterprise Architecture основана на религиозных моделях (тут согласен - они субъективны), но наука и инженерия хоть и медленно, но движутся вперед и настанет очередь ЕА (физика ЕА).
мимо (см. выше "Не совсем согласен:"). Комментарии свои почему-то удалять нельзя. Почему?
с одной стороны, очень правильно что не упомянуты ИТ системы, и пусть все знают что архитектор это тебе не айтишник, тем более EA. Так наверно проще доносить роль корп.архитектора
с одной стороны, очень правильно что не упомянуты ИТ системы,
Они появятся, но на следующих уровнях. Если конечно ИТ-системы есть в организации.
Точнее: информационная система предприятия – это не только ИТ-технологии в привычном понимании, но и вся (не только ИТ-шная) информационная составляющая предприятия, в том числе, которая (информация) существует исключительно в виде бумажных документов и циркулирует в неавтоматизированных процессах.
Схожие архитектуры на верхних уровнях могут быть идентичны для компаний с 99% уровнем автоматизации и с 1% - ным.
Кроме того, даже в компании с 99% уровнем автоматизации должны быть резервные контура, которые делают ту же самую задачу, но без автоматизации. По хорошему Disaster Recovery Plan, план ОНиВД и т.п. должны предусматривать длительные перебои с ИТ и выполнение аналогичных задач посредством "резервного бумажного контура", например, если отвалились в банке (или сразу во всех) каналы связи или перестали работать всякие клиент-банки, АРМ КБР и т.п., то печатаешь бумажную платежку и передаешь в центральный банк или в банк-корреспондент. Чем в таком "бумажном контуре" помогут ИТ-архитекторы?
Осмелюсь поправить автора статьи. Разработку EA нужно начинать не с процессов\ресурсов\продуктов, а с определения целей Предприятия. Предприятие, это не "...«цех переработки» входных внешних ресурсов в выходные продукты...", а инструмент достижения определенных целей.
Сперва определяем стейкхолдеров (учредители \ клиенты \ поставщики \ работники \ государство \ .... и т.д.) и их цели. Математика говорит нам, что задача мультикритериальной оптимизации в общем виде неразрешима - потому выбираем главную цель, а остальные цели делаем ограничениями. Далее декомпозируем главную цель (например это стоимость предприятия, и мы хотим ее увеличить) на подцели и под-под-цели и так далее. Получаем "дерево целей". Затем определеям ЧТО предприятие должно уметь делать для достижение ээтих целей - набор Капабилитиз. Затем Капабилитиз превращаем в бизнес-процессы (КАК Предприятие это должно делать). К процессам привязываем ресурсы (человеческие и материальные), которые в этих процессах используются. И это только первый слой - Бизнес Архитектура. Затем определяем слой Данных, слой Приложений и Технологический слой.
Но и это еще не все )) Такое упражнение нужно сделать дважды - для текущей EA и для целевой EA. А затем еще сделать РоадМэп перехода из текущего состяния в целевое.
Я трижды готовил компании либо к продаже либо к IPO и на каждом проекте разрабатывал EA. Не потому, что это "стильно-модно-молодежно" ))) а потому, что это очень удобный инструмент повышения стоимости. Имея текущую и целевую EA намного проще определить что нужно делать, чтобы компания стала стоить дороже.
Ваш подход часто приводится в статьях, только подробных примеров его реализации я не встречал. Можете привести пару конкретных примеров, какие цели и как влияют на архитектуру (ЕА), как на бизнес - архитектуру предприятия, так и архитектуру ИТ-систем.
Хотелось бы увидеть этот поэтапный конвейер: "дерево целей" - ЧТО предприятие должно уметь (набор Капабилитиз) - бизнес-процессы (КАК Предприятие это должно делать) - ресурсы / слой Данных, слой Приложений и Технологический слой. Звучит красиво, но вот с примерами пусто.
Я подумывал о том, чтобы выложить пример разработки EA со своего последнего подобного проекта, но передумал. Сорри. Во-первых мне нужно потратить кучу времени, чтобы обезличить все артефакты. Во-вторых, если мой как-то заказчик узнает об этом - он меня засудит и я лишусь своего гонорара )))
Попробую описать начало разработки ЕА для большого фарм.ритейлера.
Цель - увеличить стоимость компании. От чего зависит стоимость компании? От денежных потоков, дисконтированных с учетом рисков. Т.е следующий уровень целей - увличить доходы, снизить затраты, уменьшить риски. Пока все слишком очевидно. Как можно декомпозировать доходы ритейлера? Кол-во чеков х цену среднего цека. Т.е надо увеличивать кол-во чеков (кол-во покупок) и увеличивать средний чек. От чего зависит средний чек? От ассортиментной политики, от ценовой политики, от умения провизоров делать кросс-сейл и ап-сейл. От чего зависит кол-во чеков - от кол-ва покупателей и от их лояльности (т.е. как что один и тот же покупатель совершает покупки именно в нашей сети а не у конкурентов). От чего зависит лояльность покупателей? Снова от ценовой политики, от асортиментной политики, от отсуствие аутстоков (ты пришел в аптеку, а тебе говорят что лекарство только-что закончилось . нехорошо!), от удобной доступности аптек. Я не буду дальше продолжать. дерево целей может очень большим. надеюсь, что идея понятна
После того, как составлено дерево целей - составляем списко Капабилитиз и меппим их на цели самого нижнего(!) уровня. Типа: нужно уметь выбирать удобные места для открытия новых точек продаж, нужно уметь поддерживать конкурентный уровень цен. нужно поддердивать актуальную ассортиментную мартицу, нужно поддерживать необходимый уровень запаос в точках продаж, нужно быстро и недорого доставлять товар с центрального склада по цепочке поставки в точки продаж, нужно избегать очередей в точках продаж (сильно влияет на лояльность) и пр. и пр. и пр.
Зтем каждую капабилитиз разкладываем на бизнес-процессы. А как мы будем поддерживать актуалную ассортиментную матрицу? А как мы будем поддерживать необходимый уровень запаов в точках продаж? А как мы будем определять наши цены? и пр. и пр. и пр.
После того, как сотавлен списко бизнес-процессов (сгруппированных вокруг капабилитиз) - определяем, а сколько же нам нужно ресурсов чтобы эти процессы выполнять. Сколько нужно помещений аптек, кассовых аппаратов, профизоров, складсих помещений, пикапов и термобудок для доставки товара в точки продаж, погружчиков, стеллажей и пр. и пр. и пр.
Не забываем кроме группы процессов, создающих валью для потребителя, добавить еще две других группы - поддерживающие процессы (закупка, ремонты, тренинги персонала и пр) и управляющие процессы (определени целей, учет фактов,ьопределения причины отклонений и выработка управляющих воздействий). Для этих двух групп тоде нужны ресурсы.
на этом можно считать, что бизнес-слой ЕА мы закончили. Далее поередеяем дата-слой. Мне не нравиться в ТОГАФ то, что Дата выделена в отдельный слой. Я препочитаю не выделять данные в отдельный слой, а поределять их на кажлом слое, просоо с разных точек зрения.
На бизнес-слое определяем данные как бизнес-сущности - "покупатель", "поставщик", "артикул", "место хранения", "точка продажи", "чек", "заказ на закупку", "поставка" и т.д. Т.е созаем набор терминов, которыми оперирует бизнеси описываем их свойства (атрибуты)
На уровне приложений теже данные описываем в другом разрезе. Тут они уже нормализованы до 3НФ, описаны связи между ними и описаны форматы атрибутов.
на уровне Инфраструктуры описывается где в каких БД буду храниться данные, как они будут реплицироваться, бекапится\восстановляться и пр. технически аспекты
Поссле бизнес-слоя описываем слой приложений. А какие приложения помогут нам ранить бизнес-процессы быстрее, дешевле и с меньшей неопреденностью результатов? Нужна ли нам СРМ-ка или программа для оптимально оптимизации маршрутов доставки? А может нам нужна программа, помогающая рассчитывать оптимальные остатки в точках продаж? и пр.
Писать про слой Инфраструктуры не буду. Я его сам не делал. Тут мне помогали другие сабджект-меттер эксперты.
Затем повторяем все это от начала и до конца второй раз. Первый раз описывали текущее состяние. Второй раз описываем свои "хотелки".
Тут главное оценить реальность исполнения "хотелок". Если у тебя сейчас сеть из 10 шаурмичных, а в целевой ЕА ты описываешь вторую по размерам после МиккиДи сеть фаст-фудов - то скорее всего ты савишь перед собой не очень достижимые цели )))
Как раз по поводу достижимости целевой ЕА и разворачивались самые горячие споры между собственниками и топ-менеджерами )))
Когда достигнут компромис относительно целевой ЕА, остается последний штрих составить план перехода от текущего состяние в целевое. Типа: открыть еще 100500 аптек, нанять еще 100500 профизоров, купить еще с десток региональных складов, расширить автомпар на Х автомобилей, внедрить САП 4\ХАНА, СейлыФорс СРМ, написать свое новое "рабочее место провизора" (т.к. идеального решения так и не нашли на рынке) и пр. и пр. и пр.
Затем очень тяжелый этап убеждения акционеров. Типа: для реализации этого плана нужно еще вложить свои Х млн. Но зато потом сможете продать сеть на 3Х-4Х млн дороже. Ох и тяжело им это доказывать )))
Но если все-таки удалось получить "добро" от акционеров - остаются сущие "пустяки" )))
Потихоньку реализовать запланированный РоадМэп, поднять стоимость сети и получить обещанный бонус от акционеров )))
Ах да! Совсем забыл про риски. Это очень важно, хотя ТОГАФ про это приактически ничего не говоит ((
Нужно описать внешние риски, которые потенциально могут помешать нам достигнуть целей. Описать внутренние риски. Оценить их вероятности и степень влияния на целевые показатели. Определить как мы будем эти риски тритить - принимать, избегать, уменьшать каким-то образом, перекладывать на страховщиков и пр.
Акционеры обязательно об этом спросят. Луше заранее подготовтся.
К тому же уменьшая риски можно поднимать стоиомсть компании даже не увеличивая денежные потоки. Снижаются риски -> снижается коэфициент дисконтирования -> повышается стоимость компании.
Спасибо за рассказ. Первую половину подытожил:
А) Нужно Увеличить прибыль при фиксированных рисках. Составляем дерево целей:
Увеличить доходы ритейлера: 1 увеличивать кол-во чеков (кол-во покупок) + 2 увеличивать средний чек
1.1 ассортиментной политики, от ценовой политики, от умения провизоров делать кросс-сейл и ап-сейл
2.1 от кол-ва покупателей и от их 2.1.1 лояльности
2.1.1 лояльности: От чего зависит лояльность покупателей? Снова от ценовой политики, от ассортиментной политики, от отсутствие аутстоков. от удобной доступности аптек.
Б) список Капабилитиз и меппим их на цели самого нижнего(!) уровня: выбирать удобные места для открытия новых точек продаж, нужно уметь поддерживать конкурентный уровень цен. нужно поддерживать актуальную ассортиментную матрицу, нужно поддерживать необходимый уровень запаса в точках продаж, нужно быстро и недорого доставлять товар с центрального склада по цепочке поставки в точки продаж, нужно избегать очередей в точках продаж
Вопросы: 1) Разве могут быть у компании иные цели \ Капабилитиз? Полагаю, что у остальных они такие же.
2) Как мы от Капабилитиз переходим к бизнес-процессам («сгруппированных вокруг капабилитиз»)? С примерами.
3) На конкретный пример (можно переименованный \ обезличенный) «бизнес-слой ЕА» где-то можно посмотреть? Неужели нигде не встречался?
4) Разве верхнеуровневые процессы будут не типовыми? Почему не взять типовые из apqc process classification framework? https://www.apqc.org/process-frameworks
1) Конечно цели могут быть разные.
Кто-то хочет повысить стоимость компании. Кто-то хочет повысить денежный поток (это не всегда сопровождается ростом стоимости. если Повышаешь Кешфлоу за счет большого увеличения рисков - денег можеть сать больше, а стоиомть - умешьшится). Кто-то ставить целью не абсолютное увеличение кешфлоу, а отдачу на вложенный капитал. Цели неприбыльных организаций вообще не такие как у бизнес-предприятий. Если создавать ЕА, например для министерства образования, то там дерево целей буде совершенно непохожим на дерево целей аптечной сети )))
1) Конечно цели могут быть разные.
Цели неприбыльных организаций вообще не такие как у бизнес-предприятий.
Рассматриваем прибыльные, например, простую коммерческую аптеку (не сеть). Какая цель (заветная и приземленная) у обычного (среднестатистического) собственника обычной (среднестатистической) аптеки? Дерево целей?
С классической заветной целью в «300 процентов прибыли» Маркс ошибся?
Вот несколько возможных примеров главных целей:
- Прибыль
- Свободный денежный поток (который равен бух прибыли только на бесконечном интервале)
- Стоимость бизнеса (владелец планирует продать аптеку, например)
- Отдача на вложенный капитал (повышение прибыли или FCF требует дополнительных инвестиций, а их у владельца нет. Тогда он просто хочет выжать максимум из уже вложенного капитала)
- избежать банкротства (если дела совсем плохи, но хочется спасти любимую аптеку ))
В зависимости от главных целей будут разные декомпозированныей "деревья целей". Да, многие капабилитиз будут совпадать. Но приоитеты в развитии тех или иных капабилитиз будут разные для разных целей.
2) Например капабилитиз "поддерживать необходимый объем запавос в каждой точке продаж" декомпозируется в кучу бизнес-процессов. Тут нужно и определять уровень этих запаосов для каждой точки продаж (слишком большой уровень - нет аутстовков, но много денег заморожено в оборотном капитале, маленький уровень - не нужен большой оборотный капитал, но будет частые аутстовки. найти компромис - непростя задача.). Задет нужно поределять оптимальные размеры партий пополнения и часто поплнения - тоже задача весьма нетривиальная. Планировать маршруты, обрабатывать возвраты, отслеживать сроки годности запасов (очень важно для фармы, а иначе влетишь на горомные штрафы), контролировать соблюдение темературной цепочки вакцин, и пр и пр и пр. десятки БП на одну капабилитиз.
2) Например капабилитиз "поддерживать необходимый объем запасов в каждой точке продаж" декомпозируется в кучу бизнес-процессов.
Хотелось бы начать с терминов. Вроде бы и простые, но путаница: бизнес-способность
/ бизнес-возможность / карта процессов верхнего уровня.
Что мы понимаем под капабилитиз? Business Capability — это способность компании выполнять какую-либо функцию. Небольшой фрагмент дискуссии из ABPMP Russia chat: бизнес-возможность vs бизнес-способность (27.02.24):
Анатолий: если коротко, бизнес-способность - это процесс, описанный с точностью до названия, входов-выходов, владельца, показателей и целевых уровней, но БЕЗ внутреннего содержания. связь простая: на уровне процессной архитектуры описываем бизнес-способности (например, в виде vad), нижний уровень декомпозируем в bpmn.
https://bpms.ru/post/20230514-processes-and-capabilities/
Виталий: … Есть бизнес-способность (хотя мне больше нравится "Процесс верхнего уровня") - Бухучет и налогообложение. Это БП верхнего уровня в разных организациях строится по разному, в зависимости от специфики.
Анатолий: Относительно целесообразности умножать сущности бизнес-способностями: вопрос законный, по моему мнению целесообразность тут присутствует.
На верхних уровнях процессной архитектуры, действительно, нет никакой практической разницы между бизнес-способностями и бизнес-процессами (точнее, группами процессов). Но потом мы доходим до уровня конкретных процессов, например "от заказа до оплаты и поставки" или "от вакансии до испытательного срока".
Таких процессов у компании порядка 10^3. Описывать их все в виде регламентов? Многие пробовали - это путь к аналитическому параличу. Но если мы все же хотим видеть полную картину процессов компании (а многие руководители этого не просто хотят, а требуют), то можно описать эти процессы на уровне бизнес-способностей - паспортизовать, не вдаваясь во внутреннее содержание: название, место в иерархии, входы-выходы, владелец, показатели и целевые уровни. Это подъемная задача.
Заметим, что бизнес-способность это не всегда процесс в смысле повторяющейся, шаблонной последовательности действий. Это может быть проект - "мы эту деятельность рассматриваем как проект и управляем ею проектными инструментами", адаптивный кейс (см. CMMN) или вовсе "за это у нас отвечает Петрович, он полностью закрывает все вопросы".
Таким образом, вырисовываются три уровня управления бизнес-процессами:
1) архитектура бизнес-способностей - карта процессов верхнего уровня, паспортизация процессов
2) моделирование и регламентация - часть бизнес-способностей, которые требуют координации, моделируем в BPMN и генерируем из модели регламенты, содержащие инструкции исполнителям по выполнению каждой задачи
3) автоматизация - еще меньшую часть процессов моделируем так, что модель можно загрузить в BPMS и избавиться от "ручного привода", ручного контроля, отчетности, аудита и прочего майнинга
Почему нужны все три уровня: потому что это баланс между глубиной (качеством) управления и охватом. Да, хотелось бы все процессы автоматизировать (уровень 3) или хотя бы регламентировать (уровень 2). Но это достижимо не быстро, если вообще достижимо. Тут как с водкой: "выпить всю водку невозможно, но стремиться к этому надо". Поэтому вспоминаем правило Парето и где-то копаем широко, но неглубоко, а где-то наоборот.
Тут возникает вопрос об адекватном инструменте. К сожалению, с этим есть проблемы: инструменты моделирования процессной архитектуры тяжеловесны и не слишком удобны для целей регламентации, а исполнение не поддерживают вовсе. С другой стороны, разработчики BPMS искренне считают, что есть только исполняемые модели и не понимают, что компании надо а) видеть полный реестр процессов и б) иметь возможность быстро наладить регламентацию множества процессов, пока аналитики и программисты автоматизируют процессы по одному.
Cветлана: А собственно архитектура бизнес-процессов это не та же карта бизнес-способностей?
Во фрагменте «бизнес-способностей = карта процессов верхнего уровня», а у Вас вроде как иначе (декомпозируются в кучу процессов)?
Можете как-то на паре примеров для аптеки показать «десятки БП на одну капабилитиз» именно на процессах верхнего уровня. Речь ведь про верхнеуровневые БП? Вообще для обычной (среднестатистической) аптеки какие топ-10 процессов верхнего уровня? Почему у разных аптек декомпозиция (читай процессы) будет разной? "Планировать маршруты, обрабатывать возвраты, ..." - это же не процессы верхнего уровня. БП = бизнес-процесс.
Да, думаю что "капабилитиз" можно трактовать как "процессы верхнего уровня". Тут как кому удобно. Вопрос терминологии.
Вместе с
Вот несколько возможных примеров главных целей:
непонятно, почему каждая из этих целей должна требовать свой уникальный "капабилитиз" - он же карта "процессов верхнего уровня". Если для разных целей компании структура процессов верхнего уровня одинаковая, то эти цели не оказывают влияния на структуру процессов. Более того, если цели вдруг изменились (временно), то прежнюю карту "процессов верхнего уровня" на помойку и формируем новую карту из новых процессов?
3) Примеры своих ЕА никто выкладывать не хочет. И я тоже не хочу. На их разработку потрачено сотни (если не тысячи) человеко-часов. Почему кто-то должен выкладывать это бесплатно? Да и к тому же часто суровые НДА ограничивают распространение информации.
Я тоже искал примеры чужих ЕА - так и не нашел. Пришлось самому разбираться набивая кучу шишек.
Но мне повезло, что на проекте были конультанты из известного инвест-банка. Они сильно помогали советами - что и как нужно делать.
4) Нормальные типовые капабилитиз\БП описаны только для некскольких доменов:
eTOM - для телекоммуникаций
BIAN - для банков
IAA - для страховых (хотя IAA детально не изучал, просто слышал о нем)
Набор типовых бизнес-процессов для всех - это как сферический конь в вакууме. Вроде все описано, но пользы мало. (Все это ИМХО, конечно. Может кому-то APQC и помог. Мне - нет)
BIAN - для банков
Смотришь, вроде все про банки:
1 BIAN Business Capability Map или BIAN Service Landscape или презентацию
2 потом на APQC Process Classification Framework (PCF) - Banking
3 в контексте реализации ЦФТ (или иного) в виде Приложения по бизнес-направлениям
и видишь, что общего между приведенными группами картинок (подходов) – мало. Это к тому, что процессная архитектура (типовая и не очень) зависит скорее не от Business Capability \ предметной области (№3, бизнес-направления), а от «тараканов» в голове архитектора. Верно?
О каких тогда «Нормальных типовых капабилитиз\БП» можно говорить?
Простая Enterprise Architecture. Архитектура компании садоводов