КаБа

Системное сообщение

2023-06-10T18:35:00.001+03:00

Всем привет.

Я хочу вернуться к публикации своих мыслей об анализе и проектировании информационных систем. Но делать это в Телеграме.

Ссылка на канал: https://t.me/kaba_blog

Правила Голдратта, глава 1

2016-10-13T23:55:00.000+03:00

Где-то года два назад я взял у одного своего друга почитать книжку "Правила Голдратта", написанную автором теории ограничений (TOC — Theory of Constraints) Элияху Голдраттом.

Я не помню, что меня побудило уцепиться именно за эту его книгу. Но совершенно точно не теория ограничений. Я знаком с ее положениями, может быть не так детально, как многие другие коллеги, но достаточно для того, чтобы для себя решить, что TOC - это весьма удачная попытка формализовать логику принятия решений, основанную на здравом смысле. Ну т.е. чего-то выдающегося я от "Правил Голдратта" не ожидал, но читать почему-то начал.

И не зря. В какой-то момент я обнаружил, что Голдратт не просто высказывает весьма интересные мысли, но и еще умудряется попадать в те моменты, которые я для себя считаю ключевыми для развития человека как личности с независимым мнением и способностью принимать нестандартные эффективные решения. Книга начала помогать мне упорядочивать лохмотья моих рассуждений.

И я решил, что коли уж мысли стали упорядочиваться, то наверное надо это как-то фиксировать. И начал рисовать диаграммы.

Это не попытка визуализировать содержание книги. Это скорее зарисовки по мотивам прочитанного, проекция мыслей Голдратта на мое видение мира.

Продолжить чтение

Про конкуренцию и мотивацию

2016-04-30T18:15:00.000+03:00

У меня тут такая мысль возникла. Очевидная, наверняка вы с ней сталкивались и даже что-то подобное делали.

Основой эволюции является конкуренция. Система эволюционирует тогда, когда отвечает на внешние вызовы. Но при этом ответ на эти внешние вызовы рождается во внутренней конкуренции.

Получается, что если я, скажем, ограничиваю свой юнит от внешних вызовов (выступаю фильтром - буфером), то я ограничиваю возможности внутренней конкуренции и тем самым создаю условия стагнации юнита.

Я понимаю, что если я оттранслирую внешние вызовы в юнит в том виде, в котором они приходят ко мне, то это много кого шокирует и даже поубивает (как бы напрашивается ассоциация с Солнечной радиацией). Но это история другого разговора.

Продолжить чтение

Зачем менеджеру понимание архитектуры

2016-03-25T08:49:00.000+03:00

Недавно я публиковал заметку "Почему проекты умирают. Архитектура". Там я немного прошелся по тем, кто ее проектирует, но ведь началось все с понимания проектируемого продукта менеджером, точнее с того, что отсутствие этого понимания убивает проект. Но поскольку заметка носила характер выхлопа, картинок в ней не было и ряд коллег отнеслось к ней саркастически, я решил добавить картинку.

Я бы не заморочился на нее, сейчас действительно нет времени заниматься рисованием подобных очевидных вещей. Но один кейс, в который пришлось немного погрузиться на протяжении первых недель марта, посеял во мне сомнение в том, что ниже представленная картинка действительно очевидна.

Итак, па-бам! Вот она:

Глядя на нее, необходимо помнить, что процесс проектирования - это эволюционное движение от абстрактного понимания к конкретным ответам на вопрос "ЧТО?". При этом процесс управления должен не отставать и эволюционировать от абстрактного понимания к конкретным ответам на другой вопрос - "КАК?"

Почему проекты умирают. Архитектура

2016-03-13T09:01:00.001+03:00

Еще одна штука, которая очень сильно влияет на успешность проекта - это архитектура.

Пожалуй, это самый загадочный артефакт, который должен быть порожден в ходе проектирования системы.

То, что архитектруа должна быть, не вызывает сомнений ни у кого. Когда стартуется проект, ничто так часто не упоминается, как архитектура. И именно ее все хотят получить как можно скорее.

Дальше происходит магия. Когда начинаешь пинать разработку с вопросом "ну что, давайте уже с архитектурой определяться", тебе отвечают - "рано, рано, мы еще не все для себя поняли". А через пару недель на тот же вопрос ты слышишь уже другой ответ: "да уже поздно, понакодили, много менять, пусть так будет, потом разберемся".

Как понять, где эта тонкая грань между рано и поздно - лично я не знаю. Но некоторые наблюдения за таинством рождения архитектуры позволяют сделать ряд выводов, которые могут быть полезны при формировании команды.

Но сначала скажу, что под архитектурой я понимаю артефакт, описывающий структуру системы, ее компоненты и логику их взаимодействия как между собой, так и с окружающим миром. Есть артефакт - есть архитектура. Нет артефакта - нет архитектуры.

А теперь выводы:

Архитектура - это артефакт. Архитектура не бывает в голове. В голове могут быть только мысли и знания. Есть схема и описание - есть архитектура. Нет схемы и описания - нет архитектуры.
Даже самый способный и грамотный разработчик не способен спроектировать архитектуру, если он не обладает навыками и инструментами ее проектирования. Он способен "накидать". Что-то про три кубика "уровень данных - уровень логики - уровень интерфейсов". Что-то накидать - это не про спроектировать. Это про неспособность спроектировать.
Блестяще знает платформы, библиотеки, еще чего-то там и умеет проектировать архитектуры - это две очень большие разницы. См. предыдущий пункт.
Сильный системный аналитик проектирует архитектуру лучше сильного разработчика.
Схема развертывания и архитектура - это разные вещи.
Система - это не только софт, это до хрена всего. И это до хрена всего тоже является частью ее архитектуры. Поэтому у архитектора должно быть понимание, что такое система, что такое корпоративная архитектура, как его архитектура вшивается в корпоративную и что должно быть в его архитектуру включено, чтобы все сшилось. Он должен обладать кругозором.

Я хотел было закончить тем, что из разработчика архитектор выходит с трудом по той причине, что у разработчика есть определенная неприязнь к практике документирования, без которой создать архитектуру невозможно. Но причина не только в этом.

Основная причина, не позволяющая сильному разработчику стать архитектором - это зашоренность. Почему-то люди не могут увидеть ничего, кроме софта, не способны подняться выше и посмотреть на строящийся город с высоты. Умение взлететь в людях либо убивается, либо они сами в себе на протяжении карьеры убивают. Поэтому им нравится вылизывать до совершенства какие-то кирпичики, порой не осознавая, что город, который они строят - по большему счету дерьмо, которое не выдержит и пары заходов на масштабирование.

И вывод: растите архитекторов в девелоперах с самого раннего возраста. Им всем это пойдет только на пользу. Видеть больше и понимать, что делаешь, пока никому лишним не было.

Почему проекты умирают. Из ПМ-ов в администраторы

2016-03-11T14:47:00.000+03:00

Я могу ошибаться, но в реакции на предыдущую публикацию, посвященную этой теме (Как херятся проекты) проскочила такая нотка, что руководителю проекта не обязательно знать продукт, который делает команда. Мол, для этого у него есть лиды и архитектор.

Давайте в этом месте поподробнее остановимся.

Информационная система имеет некоторый жизненный цикл, который она проходит на протяжении своего создания, развития и использования с момента возникновения идеи до снятия с эксплуатации и утилизации. Туда много чего входит, всякие там приёмо-сдатка, развёртывание, интеграция, миграция и прочие вещи. Отдельные компоненты системы имеют свои жизненные циклы, существующие внутри жизненного цикла ИС.

Проект — это некоторый процесс, направленный на реализацию этапа (этапов) жизненного цикла системы или ее компонентов.

Продолжить чтение

Почему проекты умирают. Понимание продукта менеджером

2016-02-14T15:57:00.000+03:00

Эту тему начну издалека. Свою успешную карьеру инженера-разработчика я начал в конструкторском бюро, занимавшимся проектированием всякого добра для ракетно-космической отрасли. У нас там как-то сложилось так, что весь руководящий инженерный состав, начиная с главного инженера и заканчивая руководителями проектов, начальниками отделов и секторов, мыслил о продукте, отталкиваясь от его структуры и понимания логики функционирования.

Было вполне обыденным увидеть в кабинете начальника развешенные по стенам логические модели данных, схемы конструктивного деления, какие-то блок-схемы и все остальное.

Тогда мне это казалось чем-то естественным. Люди, управляя созданием чего-то, стараются понимать, как это что-то устроено и, соответственно, как этим можно управлять.

Продолжить чтение

Как повысить качество государственных сайтов?

2015-11-09T22:31:00.000+03:00

Есть вот такая статья: Как повысить качество государственных сайтов?

Говорят, по ней не прошелся только ленивый. Поэтому я тоже не буду исключением.

Поскольку эта статья породила ряд других заметок и дискуссий, я свое мнение по ней хочу высказать по схеме "тезис - мое мнение". Итак, поехали.

Продолжить чтение

Требования к информационной системе

2015-10-26T07:47:00.002+03:00

Ниже на картинке представлена структура требований к информационной системе в том виде, как я ее себе представляю.

В данную модель заложены зачатки смысла ее чтения. В частности:

все требования делятся на два вида - функциональные и нефункциональные
выделяется три уровня детализации требований - бизнес, пользовательские, системные
последовательность выявления / разработки требований в целом соответствует чтению картинки сверху вниз
длина блоков, соответствующих требованиям, субъективно (на мой взгляд) показывает на сколько этот блок требований раскрывает соответствующий вид требований
на картинке явно перечислены наиболее важные (на мой взгляд) нефункциональные требования, на самом деле их куда больше

С виду вроде ничего интересного не пропустил.

Про архитектора и аналитика

2015-10-20T22:35:00.001+03:00

Давайте поговорим о такой роли, как архитектор, точнее о тех, кого принято называть солюшен архитектором (Solution Architrect).

Для начала я расскажу, как я себе понимаю эту роль.

Solution Architrect – это роль, целью которой является проектирование архитектуры информационной системы. Под архитектурой информационной системы я понимаю некоторый артефакт, определяющий разделение информационной системы на компоненты и логику интеграции / взаимодействия этих компонентов между собой. Компоненты обеспечивают реализацию отдельных функций системы. Интеграция компонентов обеспечивает комбинированное функционирование компонентов системы, благодаря которому становится возможным достижение стоящих перед нею бизнес-целей.

В общем случае функции, реализуемые отдельными компонентами системы, не имеют конечного прикладного значения для пользователей. Т.е. речь идет не о бизнес-функциях, а о прикладной логике. Поэтому информационная система и является системой, что представляет собой совокупность программных компонентов, объединенных в такую конфигурацию, которая обеспечивает достижение поставленных целей.

Продолжить чтение

Что такое Digital Strategy?

2015-10-11T07:07:00.000+03:00

Хочу высказаться о следующей статье:

What is a digital strategy?

Mark McDonald

Managing Director, Accenture Strategy, Digital Strategy

Чем замечательна данная публикация, так это тем, что Марк определяет точку, от которой можно начинать разговор. В данном случае о digital strategy.

Марк крут. Он не вплетает в определение и пляски вокруг него всякие новомодные слова, это чистый термин и чистая идея. Здесь нет маркетинга про продать технологию, подход, себя, контору.

Другое дело, что продолжение этого разговора неминуемо приведет к необходимости понимания контекста компании, которая в своей strategy делает ставку на digital. Там сразу появляются клиенты (причем все равно, физики или юрики, Марк не сужает действие digital strategy розничным рынком) со всеми вытекающими про коммуникации, маркетинг и все остальное. Но при этом в его понимании digital strategy - это не просто про focus on customer и связанные с этим штуки, направленные на вовлечение, увеличение продаж и удержание. Это про повышение эффективности бизнеса благодаря digital.

В конечном счете это про идеологию и миссию компании, которая хочет быть эффективной во временя digital.

Еще раз повторю: прекрасное чистое простое определение, от которого можно начинать пляски с бубном вокруг digital strategy.

Agile vs. Waterfall

2015-10-07T07:22:00.000+03:00

Agile vs. Waterfall: Which Project Management Style Is Right for You? An infographic by the team at LiquidPlanner

Люблю инфографику за ее наглядность. И всегда мечтал написать о том, в чем я ни фига не соображаю. Наконец-то такая возможность предоставилась.

С этой картинкой очень сложно поспорить. Да, именно по этим причинам Agile получил право на жизнь как логическое продолжение борьбы с водопадом через совершенствование итеративного подхода. Нет, я конечно знаю, что есть люди, которые верят, что Agile к итеративному подходу не имеет никакого отношения, но лично мне проще упереться в ISO12207 и сослаться на эволюционную модель разработки: Agile - это развитие эволюционной модели.

Я просто хотел обозначить для себя некоторые моменты, которые многие при организации проектов и выборе подходов к их выполнению либо забывают, либо не обращают на них внимания:

Спор о том, что круче - Agile или водопад, не имеет никакого смысла. Равно как и вера в то, что Agile спасет мир. Тот и другой - просто инструменты, и как любые другие инструменты для них характерны цели и области применения. Успешность или не успешность того и другого есть результат правильного выбора инструмента исходя из понимания контекста проекта.
В условиях, когда у проекта зафиксировано две и более вершин проектного треугольника (сроки - цена - качество + свойства), использование Agile совершенно точно несет существенные риски, связанные с несоблюдением условий проекта.
В условиях, когда требования к продукту чётко определены и ожидаемое Заказчиком решение понятно и прозрачно, использование Agile не целесообразно. Самый простой пример таких проектов - системная интеграция.
Agile очень хорош в условиях, когда не понятно, какими свойствами должен обладать продукт и при этом нет жесткого ограничения по срокам и бюджету. Особенно он эффективен на задачах с большим творческим элементом, где нужно придумать что-то изящное и красивое. И верно обратное - в таких условиях использование водопада вызывает брутальные риски, связанные с недостижением целей Заказчика (но при этом можно спокойно уложиться в бюджет и сроки).
Водопад - инструмент, прощающий проблемы с квалификацией отдельных участников команды. Agile предъявляет к квалификации команды довольно жесткие требования. При этом кроме способности решения технических задач на лидирующие позиции выходят такие вещи, как знание предметной области, коммуникационные навыки, навыки командной работы, стрессоустойчивость, умение синтезировать решения (особенно "на лету", брейнштормом).

Лично мне Agile приятен тем, что он является своего рода возможностью возвращения специальности программиста того ореола романтизма, который был ей присущ в те времена, когда я только-только пришел в эту отрасль. Когда программист не был тупо кодером, а реально придумывал решения и воплощал их в жизнь.

Digital Strategy

2015-10-02T22:56:00.000+03:00

Я попытался на одной картинке уложить свое понимание термина Digital Strategy. Цель, которую я преследовал - выразить концепцию Digital Strategy через провязку методологий и концепций, так или иначе упоминаемых в разговорах про DS, в единую картину.

В основу я положил типовую "слоёнку" информационной системы. Слева перечислил основные идеи и тренды современных ИТ-решений, а справа перечислил методологи и технологии.

В результате получилась вот такая картинка:

Тут надо сказать, что в полном смысле термина я в Digital Strategy вообще совсем далеко не специалист. То, что здесь нарисовано - это попытка осознания. Поэтому я буду крайне признателен любой обратной связи.

UPD:

добавил CEO, CMS, BPM. Удалил IT Consulting, поскольку в моем понимании он является частью IT Strategy;
добавил Product Management.

Проектирование контекста ИС

2015-10-02T08:34:00.000+03:00

Проектирование информационной системы необходимо с чего-то начинать. С некоторой отправной точки, начав от которой можно с высокой степенью вероятности получить качественный результат.

Такой отправной точкой является контекст - модель, иллюстрирующая взаимодействие проектируемой системы с внешним миром и основные принципы её функционирования и предназначенная для того, чтобы:

зафиксировать границы решения
сформулировать общую идею решения
обеспечить полноту решения (мы должны помнить, что еще, кроме софта, должны поставить)

Для того, чтобы дальше продолжить этот разговор, необходимо сразу договориться, что мы понимаем под системой. В этом плане мне очень нравится определение из моего нелюбимого PMBOK-а: Система - это совокупность интегрированных и регулярно взаимодействующих или взаимозависимых элементов, созданная для достижения определенных целей, причем отношения между элементами определены и устойчивы, а общая производительность или функциональность системы лучше, чем у простой суммы элементов.

По смыслу информационная система представляет собой совокупность инструментов передачи, хранения и обработки данных в соответствии с бизнес-правилами, выполнение которых обеспечивает достижение стоящих перед системой бизнес целей. Поэтому проектирование системы начинается с формирования понимания бизнес-среды, в которой она будет эксплуатироваться (цели, процессы, ожидания стейкхолдеров, потребности пользователей и т.д.), а также технического окружения (смежные системы, информационные потоки и т.д.).

А бизнес-среда, техническое окружение и прочие вещи, характеризующие компанию и определяющие образ проектируемой системы, являются элементами корпоративной архитектуры.

Продолжить чтение

Можно ли жить без руководителя проекта?

2015-09-29T22:45:00.000+03:00

В ходе одной из дискуссий где-то на фейсбуке у меня возникла одна мысль, которую попробую развить ниже (с учетом того, что мне доводилось видеть).

Проектная команда - это своего рода общество с характерными для общества социальными и деловыми связями, ценностями и целями.

Руководитель проекта - это назначенный извне и сверху лидер общества.

Если руководитель проекта не обеспечивает обществу "проектная команда" выполнение условий, при которых общество остается обществом, то возможно два сценария:

Общество разваливается
Общество компенсирует нехватку лидирующей функции (либо выбором неформального лидера, либо коллективным разумом - что-то типа парламентского пролжект менеджмента)

Продолжить чтение

Ошибки организации фазы анализа

2015-09-27T14:54:00.000+03:00

Иногда меня просят включиться в проект, на котором анализ пошел как-то не так. Обычно "как-то не так" - это уже достаточно запущенная ситуация, когда с одной стороны уже потрачено достаточно много времени на достижение результата, а с другой - результат, который позволял бы утверждать, что проект движется вперед, не получен. Заказчик, видя все это, подымает красный флаг о рисках. Руководитель проекта, видя флаг и понимая, что результата нет, начинает пытаться вытолкать аналитиков из, как ему кажется, топтания на месте.

Но на самом деле они не топчутся. Они мечутся. Причина этих метаний - отсутствие идеи, как правильно делать этот проект. Ими допущены ошибки в организации своей работы. О том и поговорим.

Но для начала рассмотрим контекст. В нем участвуют четыре основные фигуранта:

Заказчик - под этим понятием мы будем подразумевать группу людей, которая заказала нам проект, готова консультировать нас по особенностям проекта, известным на их стороне, будет принимать результат нашей работы. Я воздерживаюсь от разделения роли Заказчик на такие роли, как Владелец, Спонсор, Консультант, Эксперт и т.п., поскольку это позволяет упростить все последующее повествование. Заказчик имеет по отношению к продукту определенные ожидания.
Аналитик - специалист, который должен разработать требования к проектируемому продукту.
Разработчик - специалист (группа специалистов), который должен на основании требований, сформулированных аналитиком, разработать продукт, который попадет в ожидания Заказчика.
Руководитель проекта - специалист, обеспечивающий управление проектом в целом, включая координацию взаимодействия и решение эскалированных на него проблем.

Продолжить чтение

Анализ требований при проектировании порталов

2015-03-06T23:34:00.001+03:00

Мне нравится проектировать порталы. Я всегда с удовольствием берусь за такие проекты. Мне они интересны тем, что, как правило, создание портала сопряжено с решением разнородных технических задач (таких, как интеграция, управление контентом, публикация, UXD, реализация workflow и т.п.).

При разработке порталов основная проблема, с которой мне приходилось сталкиваться, заключается в том, что объем информации, который на них хотят публиковать, достаточно большой для того, чтобы решать задачу разработки требований к порталу "в лоб".

Но ее можно прилично упростить, если структурировать содержание портала по типу его формирования. Т.е. если посмотреть на портал, то можно выделить четыре типа публикаций:

статический контент;
периодически обновляемый контент - контент, который редактируется от случая к случаю, по мере необходимости;
динамический контент - контент, автоматически формируемый на основе каких-нибудь внешних данных;
сервисы - формы, позволяющие пользователю вводить запросы и в ответ получать какие-то информационные сервисы.

Различие этих типов заключается в технической реализации их публикации.

Статический и периодически обновляемый контент требует использования CMS, поскольку механизмы управления и публикации этого контента будут одинаковы для всех бизнес-доменов / потребностей.

Динамический контент подразумевает необходимость интеграции, логика его формирования и публикации будет уникальна для каждой потребности. Сервисы - это про реализацию полноценных интерфейсов "действие - отклик", что тоже подразумевает уникальную проработку и интеграцию со смежными системами в случае каждой потребности.

Соответственно разработка требований к порталу сводится к решению следующих задач:

Определение требований к содержанию портала - какую информацию портал должен содержать для каждого бизнес-домена. На этом этапе не критично разделение на страницы и т.п. Важно структурирование информации по бизнес-смыслу. И важно понимание, откуда будет браться информация - вводиться пользователями или формироваться динамически из внешних источников. В результате должна быть получен граф, показывающий структуру публикуемой информации.
Если проектируемый портал - реально портал, с виджетами, то на основе структуры публикуемой информации определяем состав библиотеки виджетов.
Определение схемы навигации портала (разделы - подразделы - страницы). Исходя из структуры публикуемой информации разрабатывается схема навигации портала. При этом делается маппинг структуры информации на схему навигации. А затем мапаем виджеты на страницы. Также можно выделить шаблоны типовых страниц.
Классификация виджетов по типу публикации контента (см. список выше).

Классифицировав виджеты, мы в первую очередь отсекаем разработку требований к публикации статического и периодически обновляемого контента, т.к. не зависимо от бизнес-смысла и содержания реализация этой публикации будет осуществляться средствами CMS и задача сводится к распределению прав доступа и проработке правил использования CMS (шаблоны публикаций, процесс согласования и публикации контента) - т.е. это уже больше про разработку непосредственно контента, а не про требования к порталу.

Разработку требований к динамически формируемому контенту можно вести по схеме: определение требований к публикуемому содержанию - определение источников первичной информации - определение требований к интеграции и формированию контента. Оптимизация разработки требований в этом случае может быть достигнута за счет переиспользования знаний об источниках первичной информации.

Разработка требований к сервиам - классическая задача системного анализа. В этом случае каждый виджет - уникальный компонент.

С учетом всего выше сказанного в целом процесс проектирования портала обретает следующий вид:

Технологические уровни автоматизации процессов

2014-10-25T09:44:00.002+04:00

Предлагаю продолжить тему предыдущей записи разговором об автоматизации процессов.

В контексте автоматизации процессов важными возможностями, определяющими эффективность этой самой автоматизации, являются следующие:

Изменяемость процесса – услуга, инициирующая процесс, может со временем эволюционировать. Процесс должен быть автоматизирован таким образом, чтобы его можно было достаточно быстро изменять в соответствии с эволюцией услуги. Это дает возможность оперативно модифицировать услуги и выводить их на рынок.
Адаптируемость процесса к ожиданиям клиента – клиент должен иметь возможность получить услугу, которая максимально соответствует его ожиданиям. Для этого процессы, инициируемые услугой, должны обладать возможностью соответствующего конфигурирования, что дает компании способность не просто оказать определенные услуги, а предоставить клиенту максимально возможный спектр возможных вариантов закрыть свои потребности наиболее удобным образом.

Если первый пункт в большей степени реализуется благодаря продуманной архитектуре решения, позволяющей вносить быстрые изменения в процесс, то техническая сторона реализации второго пункта заключается в автоматизации процесса на основе технологий, обеспечивающих возможности его конфигурирования. Я бы сказал, что адаптируемость – это некоторая ступень автоматизации процесса, которой предшествует изменяемость.

Как может выглядеть архитектура решения, обеспечивающего изменяемую и легко адаптируемую автоматизацию процесса и на что надо обратить при анализе и синтезе такого решения – к ответу на эти вопросы я бы хотел придти в этой заметке.

Но сначала предлагаю рассмотреть вопросы, связанные с технологическими уровнями и возможностями автоматизации процессов.

Изначально создание и использование информационных систем стало возможным благодаря способности конвертировать информацию в цифровую форму (данные), что открывает возможности автоматизации управления информацией (хранение, обработка, передача, предоставление пользователям).

Способность информации быть представленной в цифровом виде определяет возможности и степень автоматизации тех или иных процессов деятельности. При этом есть два вида информации, связанной с процессом: информация-объект выполнения процесса и информация о ходе выполнения процесса. Очевидно, что максимальной автоматизации могут быть подвергнуты процессы, связанные со сбором, управлением и обработкой информации.

Первый технологический уровень автоматизации бизнес-процессов – информационно-аналитическая поддержка процесса. Она заключается в сборе, накоплении и обработке информации с целью учета, предоставления оперативного доступа, формирования отчетности и аналитической поддержки принятия решений. В качестве объекта автоматизации может выступать как информация, обрабатываемая в ходе процесса, так и информация о его выполнении.

Второй технологический уровень автоматизации бизнес-процессов – реализация потоков информации. Система обеспечивает не только управление информацией на уровне процессов CRUD (create – read – update – delete), но и реализует передачу информации от одного участника процесса другому в соответствии с заложенным в нее потоком передачи. Как правило передача информаци заключается в предоставлении доступа к информации и функциям работы с нею по факту фиксируемых в системе событий.

Третий технологический уровень автоматизации бизнес-процессов – маршрутизация потоков информации и контроль выполнения процесса. Система предоставляет пользователю возможность изменять автоматизируемые процессы и потоки информации внутри них по своему усмотрению. Механизмы маршрутизации вносят в систему определенную гибкость, позволяющую бизнесу менять процессы, скажем, в результате их улучшения или изменения контекста выполнения, а также существенно упрощают расширение информационной системы на процессы, не затронутые автоматизацией.

Четвертый технологический уровень автоматизации процессов – маршрутизация потоков выполнения работ и анализ эффективности выполнения процессов.

Возможность автоматизации процессов на каком-то технологическом уровне определяется уровнем зрелости бизнес-процессов компании.

Если за основу модели оценки зрелости бизнес-процессов взять CMMI, то возможности автоматизации процессов различного уровня зрелости будут выглядеть следующим образом:

При всей своей очевидности данная таблица навевает один очень важный вывод: возможность реализации сервисов, легко адаптируемых к потребностям клиента, возможно только при высокой культуре организации процессов предоставления этих сервисов. Если же речь идет о реализации парадигмы omni channel, то требование к зрелости процессов становится критическим.

Что касается автоматизации процессов, обеспечивающей их изменяемость и адаптацию к ожиданиям и потребностям клиента, то такая реализация может быть осуществлена на третьем либо четвертом технологических уровнях.

Определение бизнес-процесса

2014-09-12T02:29:00.000+04:00

Ребяты, ниже будет про то, как я понимаю определение бизнес-процесса.

Основная идея заключалась в том, чтобы отрисовать модель термина «бизнес-процесс» так, чтобы она показывала те свойства процесса и зависимости между элементами его определения, которые открывают возможность его автоматизации.

В итоге получилась вот такая диаграмма (UML, диаграмма классов):

Из модели следует, что определение процесса открывает три механизма его автоматизации:

автоматизация активностей, входящих в состав процесса;
автоматизация информационных потоков;
автоматизация событийной модели (автомат).

Эти три механизма определяют цели анализа бизнес-процесса при разработке требований к его автоматизации, а возможность их реализации ограничивается свойствами процесса и влияет на цели его автоматизации.

Полнота реализации этих механизмов определяет технологический уровень автоматизации процесса (об этом будет позже, я утерянную было заметку уже почти нашел).

Про чтение профессиональной литературы

2014-08-02T09:08:00.001+04:00

Когда кто-то говорит, что тратит свободное время на чтение профессиональной литературы, для меня это звучит странно. Не, найти ответы на возникшие вопросы - ок, но прямо читать - это на мой взгляд перебор.

Из профессиональной литературы за свою жизнь от и до я прочитал только одну книгу. И это был не Вигерс и не бабук, которые были пролистаны за 25 минут каждый.

В моем понимании вместо того, чтобы читать книги или шарахаться по тренингам гораздо полезнее взять пресейл и убить три дня свободного времени на то, чтобы сделать его так, чтобы ПМ с аккаунтом раскрыли рты до вывиха челюсти, когда его увидят. Это дает в разы больше, чем если все это время читать, как кто-то учит работать.

Более того - твой опыт создает твою личную уникальную экспертизу. Опыт книжек делает тебя инкубационным специалистом. Одним из толпы таких, как все.

Книжка пишется год - два, год издается. Плюс наработка опыта автором. Ты читаешь о том, как работали в лучшем случае лет 5 назад. В условиях динамично развивающегося рынка это как изучать схемотехнику на примере ламповых приемников.

Моя уверенность заключается в том, что для того, чтобы стать профессионалом своего дела, тебе надо три вещи: много работать, делать свое дело лучше остальных и стараться попадать в команды, где работают профессионалы (это касается и твоей специализации, и смежных). А еще надо любить свою специальность.

Про трудоголизм

2014-07-08T23:45:00.000+04:00

Одна из проблем, с которой иногда приходится сталкиваться на работе - трудоголизм.

Трудоголики опасны.

Они сжигают свое время на работе, почти ничего не оставляя для хоть какой-нибудь личной жизни.

Их целью является работать работу, но не достигать резульата.

Они попадают в общее благоприятное представление о тех, кто работает сверхурочно: "ах, они решают наши проблемы". На самом деле они их создают.

Трудоголики создают проблемы.

Потому, что мозг не способен долго работать с высокой нагрузкой. В какой-то момент происходит переключение с активной мыслительной деятельности в режим расставления галочек. Человек, постоянно находящийся в работе, теряет способность решать сложные задачи и принимать сложные решения. Он отрубается. И это создает проблемы тем, кто зависит от результата его работы.

Более того, поскольку уставшему мозгу тяжело принимать эффективные решения, трудоголик далеко не всегда способен выбирать оптимальный путь решения поставленных задач, что усугубляет и без того падающую от усталости эффективность работы. И убивает работу команды, направляя ее силы на преодоление личных проблем трудоголика.

Но у трудоголиков есть преимущество: создавая проблемы, они потом способны напрячься и решить их. Внеурочно, вваливая по 16 часов в сутки. И в глазах руководства они становятся героями. Потому, что когда проблема решена, мало кто вспоминает, почему она появилась.

А еще трудоголики создают комплекс неполноценности у тех, кто умеет организовать свое время, сделать все в срок и вовремя уходит с работы.

Про инновационную культуру в компании

2014-07-07T21:33:00.001+04:00

FutureBanking в очередной раз порадовал шикарной статьей. Она называется так: "Как создать инновационную культуру в банке?"

На мой взгляд, статья чуть шире, чем про банки. Она про компании в целом. Я для себя нашел в ней много чего такого. Как утверждающего правильность моей жизненной позиции, так и заставляющего что-то в себе поменять.

Далее только цитаты (которые мне показались мне наиболее интересными), дополнить это чем-либо мне сложно.

Цитаты:

Опыт последних месяцев показывает, что зачастую даже у самых успешных компаний, когда у них начинаются проблемы с корпоративной культурой, падают финансовые результаты.

Всё зависит от того, на какую перспективу вы строите компанию: тоталитарный строй в истории всегда показывал феноменальные успехи на коротких временных промежутках и был абсолютно не приспособлен к переменам, в результате чего быстро разваливался; демократические же государства выигрывают в долгосрочной перспективе, хотя поддержание таких условий является очень затратным делом и требует больших временных затрат на все процессы.

Продолжить чтение

CJM: UX-дизайнер? Подвинься, детка, тут поляна бизнес аналитика!

2014-07-02T10:17:00.000+04:00

Это презентация к воркшопу про CJM. Авторы - +Юлия Фокина и +Yuri Vedenin

Ниже под катом - тезисы (из-за них все это и выкладываю). Кстати, самые офигенные из всех тех, в написании которых мне приходилось поучаствовать. Респект напарникам!

Продолжить чтение

Дьявольский аккорд. Карьера как по нотам

2014-07-02T10:03:00.001+04:00

Это наш совместный с +Юлия Фокина доклад про выбор альтернативных направлений развития аналитика и выстраивание плана профессионального развития.

Ниже под катом - тезисы доклада.

Продолжить чтение

Почему большие банковские мобильные приложения необходимо беспощадно дробить на малюсенькие

2014-06-26T01:22:00.000+04:00

В общем-то очевидная вещь: чем крупнее мобильное приложение, тем тяжелее с ним управляться и тем меньше желания с ним иметь хоть какие-то отношения.

Напрашивается идея дробления больших решений на решения поменьше. Но опять вопрос - по какому принципу долбашить? По функциональному? Или из понимания архитектуры? Или еще как-то так, как в голову с ходу не приходит?

В общем когда мы в этот вопрос уперлись (мы - это я и +Юлия Фокина), у нас спонтанно появилась вот такая картинка:

Что хотелось этой картинкой сказать... Когда клиент обращается к мобильному приложению, он это делает исходя из необходимости добиться какого-то результата (цель), значимого в контексте его жизненной ситуации. Т.е. жизненная ситуация диктует ему, какой функциональностью воспользоваться. А опыт все это дело усугубляет ожиданиями от результата и пути его достижения.

Отсюда возникает идея, что дробить большие решения на набор мелких предпочтительно исходя из пересечения двух пониманий:

жизненный опыт целевой аудитории;
жизненные ситуации, в которые целевая аудитория попадает.

В общем случае из этого следует, что одни и те же функциональные возможности могут быть представлены и реализованы совершенно по разному и даже не два-три раза. Всё зависит от того, на сколько плотно и комфортно мы хотим покрыть жизненные ситуации клиентов с учетом их опыта.

Поэтому реализуемая Credit Agricole идея создания среды взаимовыгодного сотрудничества клиентов, сторонних разработчиков и банка, направленного на постоянное расширение мобильного функционала, пока что выглядит очень перспективно.