Я работаю в сфере консалтинга и сейчас возникло сомнение в определении, и позиционировании моей деятельности. У меня за плечами более 12 лет опыта предпринимательства (успешного и не очень), управления проектами, запуска стартапов, а также продуктивный опыт антикризисного управляющего.
На протяжение последних двух лет занимаюсь консультацией других компаний по вопросам развития, повышения эффективности и результативности. Все это время я определял себя как “Бизнес-консультант”. Но учитывая тот факт, что помимо консультаций я помогаю внедрять разработанный план изменений, то на мой взгляд, определение “Бизнес-консультант” не совсем полно отражает суть моей деятельности и приносимую ценность. Возникла идея обратиться к целевой аудитории и коллегам по цеху, чтобы получить обратную связь. Может уже есть определение для такого рода деятельности, а я просто его не знаю?
По сути, я занимаюсь разработкой инновационных-бизнес моделей с последующим их тестированием и внедрением. Большой упор делается на разработку ценностного предложения (далее ЦП) и создание системы, чтобы предоставление этого ЦП было коммерчески эффективно. Проще говоря, чтобы бизнес получал желаемую прибыль.
Бизнес-архитектура компании, с чего начать и как развивать?
Я считаю, что отправной точкой при для повышения эффективности и результативности бизнеса служит создание инновационной бизнес-модели, так как это является универсальным инструментом для начала стратегического и тактического планирования.
В своей работе я использую бизнес-модель как фундамент для дальнейших преобразований. Описание текущей модели помогает выявить где мы есть сейчас, а процесс ее обновления (инновации) показывает нам точку куда мы стремимся, какие шаги необходимо сделать для изменений и построения экономически эффективной системы, что у нас уже имеется и каких элементов нам для этого не хватает, а также системно создавать и улучшать конкурентные преимущества. На основе бизнес-модели можно:
- Посмотреть на свой бизнес со стороны, увидеть зону для оптимизации, процесс создания стоимости.
- Быстро протестировать идею нового проекта/продукта
- Создать лучшее на рынке ценностное предложение, расширить или создать рынок
- Разработать стратегический план развития и преобразований.
- Описать финансовую модель и оценить экономическую эффективность нового проекта или действующего бизнеса (модель выручки, модель маржинального дохода, модель операционных затрат и т.д.)
- Описать бизнес-процессы и выявить ключевые узлы для непрерывного улучшения качества
- Сформировать организующую схему и команду проекта
- Определить ключевые компетенции и план обучения
- Разработать маркетинговую стратегию
- Определить ключевые показатели бизнеса и метрики для отслеживания прогресса реализации стратегии преобразований
Все вышеуказанные пункты и являются полем моей деятельности от анализа и разработки до внедрения и совершенствования. Можно создать и улучшить как систему в целом, так и отдельные ее элементы.
От архитектуры бизнеса к архитектуре процесса
В своей работе я использую теорию и прикладные методы из сфер инновационного бизнес-моделирования, методологии Адизеса, Деминга, Теории Ограничения Систем Голдратта, Hubbard Management System, Customer Development, Blue Ocean Strategy, Lean Startup и другие. В зависимости от уровня развития компании и ситуации использую различные методы. В следующих постах я подробнее опишу используемые методы.
По факту, больше всего мне нравится тема инноваций бизнес-моделей и ценностного предложения (особенно если получается найти или создать “голубой океан”), так как эта деятельность больше всего соответствует моему духу предпринимателя и новатора. Отсюда и родилось еще одно определение “Архитектор Инновационных Бизнес-моделей”. Но я прекрасно понимаю, что пользы от этих разработок не будет, если их не внедрить в бизнес. Если оставить внедрение на “совести” собственников проекта, в большинстве случаев, все разработки ждет участь “запыливания” в ящике стола. Основным критерием успеха своей деятельности я считаю практическую пользу и не хочу быть одним из многих консультантов, которые просто отрабатывают свои “человекочасы” и выдают тонны макулатуры с графиками, таблицами и описанием того “как это нужно правильно сделать”, вместо того, чтобы помочь заказчику сделать это.
А теперь, внимание вопрос: какое определение больше всего, на Ваш взгляд, подходит для данного рода деятельности? Так, чтобы коротко и емко:) И возможное ее позиционирование на рынке? Варианты, которые пришли мне в голову:
Бизнес-консультант
Архитектор инновационных бизнес-моделей
Эксперт по развитию бизнеса
Бизнес-архитектор
Эксперт по системной инновации конкурентных преимуществ
Другое. Предложите свой вариант в комментариях
Показать результаты
Переголосовать
Проголосовать
Чтобы ваша помощь мне не была односторонней, по всем канонам принципа Win/Win, я хочу предложить всем откликнувшимся на мой запрос абсолютно бесплатно оказать помощь в описании Вашей текущей модели бизнеса и предложить несколько (от 3 до 5) инновационных преобразований бизнес-модели или ценностного предложения, с описанием способов быстрого тестирования этих гипотез. А также, на ваш e-mail я пришлю пошаговую инструкцию экспресс-метода генерации идей для инновации вашей бизнес-модели. Вы можете оставить ваш e-mail в комментарии или пройти по ссылке: ib-m.ru
Заранее спасибо за Вашу обратную связь!
Показать ещё
76 комментариев
Написать комментарий.
не хочу быть одним из многих консультантов
выдают тонны макулатуры с графиками, таблицами и описанием того “как это нужно правильно сделать”, вместо того, чтобы помочь заказчику сделать это
я пришлю пошаговую инструкцию экспресс-метода
бизнес-консультант не может сам себя проконсультировать о том как ему позиционироваться?
Развернуть ветку
Бизнес-консультант ищет свободные уши =)
Развернуть ветку
Это брендинг и нейминг тип))
Развернуть ветку
Развернуть ветку
Развернуть ветку
1 комментарий
Эксперт по развитию бизнеса. Не знаю, кто Ваш частый клиент, но если углубляться в провинцию, то чем проще для понимания самоидентификация, тем проще найти клиента и презентовать себя и услуги. В целом все, чем Вы занимаетесь — это очень здорово! Очень хотел бы обсудить с Вами мой бизнес. [email protected]
Развернуть ветку
Я, конечно, не бизнес-консультант, но может Вы зарегистрируете почту на свое домене, а не общественном?
Стоит почти ничего, а с точки зрения бизнес-этикета — +100 к карме.
Развернуть ветку
2 комментария
Вы правильно поняли вопрос,чтобы было просто и понятно) Спасибо за отклик, в ближайшее время свяжусь с Вами по email
Развернуть ветку
Назовитесь бизнес-консультантом высшей категории им. ордена трудового красного знамени
Развернуть ветку
забыли написать: Всея Руси 🙂
Развернуть ветку
Когда компания обращается к бизнес-консультантам, это говорит о том, что главная проблема этой организации в том, что у них недостаточно управленческой воли и организации для эффективного управления компанией. Поэтому вопрос в том, где причина всех неудач у компании вообще не стоит, это сразу понятно. Отсюда сразу выходит второй вывод, чтобы вы там не наконсультировали ничего исполняться и внедряться не будет, опять же из-за отсутствия управленческой воли. В данной ситуации можно сделать две вещи — это получить на себя максимальные полномочия на управление организацией(т.е. стать, грубо говоря, ее директором), либо получить контроль над ЛПРом, полностью влияя на принятие им решений.
Т.о. первичная консультация ЛПРа должна заключаться в том, чтобы понять насколько он манипулируемый и управляемый со стороны, как правило, коммерсы все упертые бараны, поэтому максимум на что можно надеяться это сделать пару томиков рекомендаций и описаний бизнес-процессов, которые компания положит в стол, когда вы уйдете, главное взять за это все большую предоплату. И все это бестолковое занятие.
Таким образом зерно вашей деятельности — это взятие под контроль ЛПРа организации, т.к. для этого нужно быть очень хорошим продажником и нейролингвистическим программистом, то лучше всего суть вашей деятельности отражает фильм Начало с Леонардо Ди Каприо от 2010 года. По английски Inception. В итоге наилучшим названием для вашей деятельности будет Инсептор(прерыватель сна).
Пожалуйста, за консультацию.
Развернуть ветку
Посмотрел перевод слова Inceptor — оказалось, что это латынь)
Дословный перевод: инициатор, зачинатель, начинающий.
Если использовать его в контексте Инициатор изменений (или перемен), то Вы подобрали слово на 100% «в яблочко» :))) Возьму его в лексикон, с Вашего позволения ))
Inceptor of changes — получается если скрестить латынь и английские слова:)
Развернуть ветку
У вас такой консалтинг из влажных снов интерна в маккинзи, еще не вышедшего на работу. Вот он такой — в костюме, берет сложную (лол) методику. За пару часов по ней понимает в чем проблема, эффектно презентует заказчику, отвечает на сложные вопросы и едет сниматься со стресса к дорогой проститутке с кутузовского.
Если всерьез, то сейчас ситуация, что бы не в политических целях а по серьезу, дернули big3 разрабатывать стратегию для серьезной организации — очень мало, если вообще есть.
В реальности — консалтинг это все больше про кадровое агенство, которое быстро способно предоставить умный, мотивированный и квалифицированный персонал, который готов работать по 12-14 часов в день. И делать довольно грязную работу — занудные исследования рынка, где очень много ресерча и надо много сводить, обрисовывать сотни процессов, и оценивать их стоимость и тд. Ну и бест практис на с рынка.
К управлению процессом, а тем более к принятию решений по изменению стратегии никто консультантов не допустит. Почему — это отдельный вопрос, про изначальную суть консалтинга и нынешнее состояние. Ни к какому ЛПР никто из консультантов не пойдет.
Топик стартеру интересно завязать дискуссию плюс насрать в уши предпринимателям у которых не очень с английским, критическим мышлением. Как обычно, поменять свой базар на твое сало.
Развернуть ветку
7 комментариев
Интересная аналогия) Но не со всем я согласен, особенно с методами проведения изменений через манипуляцию.
Соглашусь с Вами, что на проведение изменений в организации нужно желание ЛПР, но здесь больше подходит слово поддержка или одобрение.
На моей практике вопросов с волей обычно не стоит. Стоит вопрос куда эту «волю к преобразованиям» направлять, нужен взгляд со стороны. По идее эту роль стратега, освобожденного от «операционки», должен выполнять учредитель, но как правило Исполнительный директор и есть собственник бизнеса. Операционка занимает все его время и он может просто не видеть очевидных вещей, которые губят его бизнес.
Развернуть ветку
2 комментария
Это классический Business development. Хотя в наших широтах BD связывают с продажами, а не построением/разработкой ))
Вам обязательно русское название?
Развернуть ветку
Я думаю, что желательно русское и без транслитераций, чтобы потом не приходилось долго объяснять смысл этих «импортных» слов:)
Развернуть ветку
2 комментария
[email protected]
У меня сеть кофеен и Кофе баров в городе Калуга. Работаю пятый год.
Развернуть ветку
Иванов И.И. Решаю вопросы.
Развернуть ветку
Согласен. Я тоже об этом задумывался, что при слове Архитектор будут ассоциации со строительством.
Источник: vc.ru
АКИС (10) — Лекция №9 — Бизнес-архитектура
Построение бизнес-архитектуры начинается с общего обзора ситуации, который предполагает поиск ответов на следующие вопросы:
- Каков внешний контекст деятельности организации?
- В чем состоят основные функции и добавочная стоимость, которая является итогом деятельности организации?
- Какие сценарии развития бизнеса необходимо учитывать, и какова вероятность их реализации?
- Какие необходимы информационные взаимосвязи и процессы обработки информации?
Усилия по построению бизнес-архитектуры, которая представляется в виде бизнес-моделей, быстро окупают себя и имеют большое количество дополнительных преимуществ. Под бизнес-моделями понимается динамический поток событий, связанных с бизнесом, в который вовлечены различные функции бизнеса, организационные единицы и активы предприятия. Возможная отдача от реализации таких моделей достаточно подробно изучалась и описывалась на протяжении последнего столетия. Основная проблема состоит в том, чтобы убедить руководство в этих преимуществах и добиться от него поддержки проведения проекта разработки бизнес-моделей.
А преимущества от построения таких моделей лежат в двух плоскостях: дополнительных возможностях для бизнеса и уменьшении затрат. По оценкам, создание бизнес-моделей и связанная с этим оптимизация затрат даже без радикальных изменений бизнеса может дать до 10% экономии.
А при моделировании альтернативных вариантов бизнес-процессов организации могут сэкономить до 20%. Но не менее важная роль бизнес-моделей состоит в том общем языке, которые они дают представителям бизнеса и ИТ в обсуждении соответствующих возможностей.
Принципы, модели и стандарты
Основные составные элементы стратегии и архитектуры информационных технологий предприятия можно отобразить условно в виде следующей пирамиды, представленной на рисунке:
Из данного рисунка видно, что руководящие принципы, так же как и стандарты политики, руководства, процедуры, могут относиться абсолютно ко всем элементам архитектуры: и к данным, и к прикладным системам, и к технологической инфраструктуре.
Важно отметить, что для описания «верхней» части этой пирамиды используются, в основном, такие механизмы, как декларируемые принципы. «Средняя» часть пирамиды, т.е. непосредственно архитектура, описывается в форме набора соответствующих моделей. А нижняя часть пирамиды связана с выработкой соответствующих правил, процедур или выбором стандартов.
Ключевыми элементами, с точки зрения архитектуры, являются принципы, стандарты и модели. Стандарты разрабатываются на основе принципов и описывают, как принципы будут реализованы на практике. Модели являются графическим представлением принципов и стандартов и используются для описания архитектуры. При этом модели обеспечивают упрощенное представление о сложном реальном мире и создают абстрактные конструкции, в которых опущены несущественные детали и внимание сосредоточено на наиболее важных аспектах описываемого предмета. Кроме того, модели обеспечивают основу для обсуждения между различными заинтересованными сторонами одного и того же предмета.
Реализация целей, задач и стратегий достигается через соответствующие ИТ-проекты, которые формулируются в планах на очередной период деятельности.
При этом можно рекомендовать использование следующей иерархии отношений между политиками, стандартами и процедурами. Стандарты всегда должны быть связаны с некоторыми сформулированными политиками, хотя сами политики могут и не иметь определенных стандартов «под собой». Точно так же процедуры всегда должны быть связаны с определенными стандартами, хотя сами стандарты могут существовать без связанных с ними каких-либо процедур.
В этих условиях первое, что архитектура предприятия должна дать сразу и всем участникам процесса – это общие рекомендации по текущим проектам, чтобы их руководители могли понимать общее направление. Первым правилом является правило «не навреди», что и означает задание общего для всех стратегического направления. Это достигается через формулировку принципов, которые для этого являются очень мощным инструментом. Принципы – это высокоуровневые руководства к действию. Примером принципа может быть следующий: «Мы будем использовать передовые технологии, но только не самые новейшие и непроверенные».
Ниже приведены примеры общих принципов, связанных с архитектурой в целом:
- все подразделения (ведомства) должны использовать в своей работе архитектуру, разработанную для организации (правительства) в целом;
- функциональное руководство и руководство в области ИТ должно основываться на общем видении;
- архитектура должна обеспечивать решение вопросов бесперебойного выполнения организациями своих функций, безопасности и восстановления в случае катастрофических событий;
- функциональные (бизнес-) требования должны формировать архитектуру;
- архитектура должна обеспечивать совместимость и взаимодействие;
- архитектура должна быть расширяемой, масштабируемой и адаптивной;
- архитектура должна быть инструментом реализации изменений;
- архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов;
- тенденции рынка должны учитываться при проектировании технологической архитектуры.
Примеры декларируемых принципов в области ИТ-инфраструктуры:
- инфраструктура должна быть основана на использовании технологий, поддерживающих открытые стандарты;
- инфраструктура (совместно с принципами управления данными и разработки приложений) должна обеспечивать взаимодействие систем.
Примеры принципов в области управления данными:
- бизнес-структуры (отделы, департаменты, ведомства), являющиеся владельцами данных, отвечают за целостность и распространение данных;
- данные уровня отдельных бизнес-структур (департамента, региона, города) должны быть явно описаны и доступны всем остальным бизнес-структурам (департаментам, ведомствам);
- ведомства собирают только самый необходимый минимум данных и стремятся уменьшить нагрузку на тех, кто должен предоставлять данные;
- данные вводятся в информационные системы один раз, и тут же выполняется проверка их корректности;
- информация является ценным ресурсом, который передан в управление менеджерам (государственным служащим), и этим ресурсом необходимо соответствующим образом управлять.
Примеры принципов, связанных с прикладными системами:
- прикладные системы разрабатываются на основе стандартной, единой методологии;
- все структурные подразделения (ведомства) используют общие методы представления информации пользователям в своих приложениях и координируют работы по созданию пользовательского интерфейса межфункциональных (межведомственных) систем;
- создание межфункциональных прикладных систем приветствуется;
- руководство заранее планирует процесс замены устаревших прикладных систем.
Примеры принципов, связанных с управлением и контролем:
- единая архитектура, соответствующие стандарты и руководства используются всеми структурными подразделениями (ведомствами) в процессе принятия решений о своих информационных системах;
- стандарты пересматриваются регулярно не реже одного раза в два года с участием представителей структурных подразделений (ведомств);
- руководство структурных подразделений (ведомств) стремится к кооперации и партнерству с другими структурными подразделениями (ведомствами) в области информационных технологий.
При разработке и использовании стандартов следует учитывать нижеперечисленные аспекты:
- уделять большее внимание тем стандартам, которые обеспечивают эффективное использование базовых технологий. Прежде всего, это технологии, на которых построены многие системы и которые стали индустриальными стандартами. Примерами таких технологий для организаций являются XML, .NET, Java (рассматриваемая не как язык, а как среда разработки);
- определять стандарты процессов. Примерами являются процессы бизнес-моделирования, методы разработки систем, тестирования, интеграции;
- уделять внимание интерфейсам. Понимание интерфейсов является основой для интеграции систем;
- теснее взаимодействовать с бизнес-подразделениями. Например, разработка основанных на XML стандартов на электронные сообщения невозможна без участия специалистов в конкретных предметных областях;
- для того чтобы быть эффективным инструментом, стандарты должны включать списки конкретных версий технологий, интерфейсов программирования (API), утилит и т.д. Примерами могут быть версии систем управления базами данных, версии XML и т.п;
- стандарты должны включать способы проверки на соответствие;
- стандарты должны содержать описание того, как организован процесс их поддержки. Стандарты должны периодически пересматриваться и обновляться.
- Архитектура корпоративных информационных систем (10 семестр)
- Конспекты лекций и семинаров
Источник: iu5bmstu.ru
Моделирование бизнеса и архитектура информационной системы. Модель Захмана
В 1987 году Джон Захман опубликовал полезную схему развития архитектуры информационной системы. Дж.
Захман определил архитектуру предприятия как «набор описательных представлений (моделей), которые применимы для описания предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)». Термин «архитектура» здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия и сложного искусственного объекта, такого как, например, здание. Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture). В исторически сложившемся переводе названия на русский язык используется именно термин «модель», отражающий, прежде всего, четкую формальную структуру предложенной Захманом конструкции, хотя по глубине подхода и значимости, скорее, должен был быть применен перевод оригинала » framework » как «методики».
Модель Захмана преследует две основные цели – с одной стороны, логически разбить все описание архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной архитектуры с выделенных точек зрения или соответствующих уровней абстракции.
В то время, когда были опубликованы работы Захмана, традиционным подходом при формировании описания системы являлось использование концепции «жизненного цикла». На каждом из этапов жизненного цикла рассматриваются вопросы, связанные как с функциями системы, так и с данными. Захман предложил вместо традиционного подхода, связанного с рассмотрением отдельных аспектов работы системы как бы в различные моменты времени, использовать рассмотрение системы с различных перспектив.
Исторически модель Захмана впервые была создана именно для ИТ‑систем [1]. Этот подход в дальнейшем был обобщен для рассмотрения не только ИТ‑систем, но и для описания предприятия в целом, так что предложенная модель может использоваться как средство для описания архитектур сложных производственных систем любого типа.
Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рис. 3.1 (в русском переводе [2]). Заметим, что в модели именно пять строк, просто отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Рис. 3.1. Модель Захмана
Перспективы (строки в таблице) могут, в частном случае, соответствовать различному уровню управления предприятием, если речь идет об архитектуре предприятия или использования информационной системы.
Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. Если проводить аналогию со строительством, то эти уровни содержат сведения о местонахождении и назначении постройки («особняк» для отдыха в престижном коттеджном поселке в элитной зоне), а также диаграммы, планы и картинки, которые архитектор обсуждает с хозяином будущего дома. Следующий уровень «логической модели» уже является более конкретным, но все равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен показывать подрядчикам.
Аналогично, в применении к деятельности предприятия верхняя строка » Контекст » соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень » Модель предприятия » соответствует интересам бизнес-менеджеров и владельцев процессов. Третий уровень » Модель системы (Логический уровень)» – это уровень, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков.
– используемые данные (что?)
– процессы и функции (как?)
– места выполнения этих процессов (где?)
– организации и персоналии–участники (кто?)
– управляющие события (когда?)
– цели и ограничения, определяющие работу системы (зачем?)
Основные правила заполнения таблицы следующие:
· каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы («базис»);
· порядок следования колонок несущественен;
· каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
· базовые модели для каждой из колонок являются уникальными;
· соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
· заполнение клеток должно проводиться последовательно «сверху вниз», попытка пропуска одного из рядов является, скорее, «шаманством» (в том плане, что нельзя создать хорошо работающую систему, «перепрыгнув» определенные уровни ее описания на этапе проектирования).
Рассмотрим заполнение строк.
Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – «Мотивация»). Фактически, данная строка определяет контекст всех последующих строк.
Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.
Третий уровень (логическая модель) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Рассмотрим теперь, как осуществляется последовательная детализация отдельных аспектов описания системы, для чего обратим внимание на различные колонки таблицы. Напомним, что порядок расположения колонок в таблице, вообще говоря, произволен.
Первая колонка отвечает на вопрос » ЧТО?» и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе.
На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы «сущности-связи» (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Пятый уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т. п. Конечно, можно отметить определенное несовершенство данной модели при использовании объектно-ориентированного подхода – фактически модель предписывает раздельное рассмотрение данных (свойств) и функций (методов) классов.
Колонка функций (ответ на вопрос » КАК?») предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям.
Следующая колонка (вопрос » ГДЕ?») определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов.
На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети.
Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое «middleware»), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.
Колонка таблицы, отвечающая на вопрос » КТО?», определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли, требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.
Пятая колонка отвечает на вопрос » КОГДА?» и определяет временные характеристики бизнес-процессов и работы системы. Детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2).
На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы.
Последняя колонка (» ПОЧЕМУ?» или «ЗАЧЕМ?») служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию.
Важным принципом модели Захмана является необходимость последовательного перехода при углублении детализации рассмотрения. Пропуск отдельных элементов, например, прямой переход от описания модели бизнес-процесса к физической реализации системы требует «привлечения магии» и почти всегда приводит к неудаче. На практике это часто случается при попытке разработки программы на основании только устного описания требований пользователя.
Рассмотрим, как может использоваться модель Захмана на практике. Во-первых, данную модель удобно применять для классификации всей информации, описывающей предприятие и информационные системы этого предприятия, выявления «белых пятен» и координации работ.
Во-вторых, данную модель можно использовать на метауровне – для сравнения различных реализаций создания архитектур предприятия. В‑третьих, она может являться удобным средством для использования в отдельных проектах. Например, в проекте по созданию корпоративного информационного портала необходимо определить элементы в строках 3-5 колонки 4 – соответственно, требования пользователей к представлению данных, интерфейсы и спецификацию по разграничению доступа с учетом существующих «унаследованных» компонент информационной системы. Эта существующая технологическая архитектура, в свою очередь, рассматривается в ячейке на пересечении четвертой строки и третьего столбца таблицы.
У модели Захмана имеются недостатки. Один из них заключается в том, что при применении модели на практике возникают определенные трудности, связанные с отсутствием «встроенного механизма» распространения изменений между элементами таблицы. Действительно, предположим, что изменилась организация процесса поставок в компании (схема логистики). Это потребует отслеживания «вручную» всех взаимосвязей, проверки актуальности и внесения изменений в модели и другие артефакты во всех потенциально «затрагиваемых» ячейках.
Другим ограничением модели является отсутствие рассмотрения системы в динамике. Действительно, каждый элемент таблицы может содержать как описание существующего состояния («как есть»), так и целевого, а также всех промежуточных состояний. При этом сама модель не содержит средств для четкого разделения этих различных «временных срезов».
Кроме модели Захмана известны и другие модели архитектуры предприятия [2].
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru