MaksWiki - Новые страницы [ru]

Необъектные модели предметной области. Опыт CUSTIS (Максим Цепков, ADD-2011)

2011-05-15T16:55:37Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про DDD}}

Доклад на конференции Application Developers Days 29-30.04.2011 Питер
Видео https://vimeo.com/23899443

Когда всем понятно

2011-05-10T17:07:08Z

MaksTsepkov:

Максим Цепков - главный архитектор компании CUSTIS

Бухгалтер и компьютер, № 5(май), 2011
Журнал закрылся, архив недоступен. 
Более глубокий рассказ был в Санкт-Петербурге Международном экономическом симпозиуме — Соколовские чтения: доклад в 2017 и в 2018.

Когда всем понятно. Диаграммы учета: мост между бухгалтером и разработчиком

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

Эффективное представление информации
Информацию нужно уметь представлять в наглядном и компактном виде, позволяющем быстро охватывать картину в целом, рассуждать, передавать знания другим людям. Примером эффективного представления данных может служить современная алгебраическая запись уравнений, созданная в XVI—XVII веках Виетом, Декартом и другими математиками. До этого уравнения записывались словами, и, чтобы понять смысл формулы, требовалось интерпретировать текст достаточно большого объема, который алгебраическая запись свела к одной компактной формуле.
Развитие науки показало, что многие виды информации можно эффективно представлять в виде диаграмм, а достижения информационных технологий позволили эти диаграммы быстро и легко строить и изменять. В настоящее время представление данных в виде диаграмм является общепринятым и интенсивно развивается, поскольку даёт компактную и наглядную целостную картину, с которой можно эффективно работать, обращаясь к детальной информации только по необходимости. Множество графических решений используется и для описания бизнес-процессов.

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

SoftwarePeople-2011

2011-05-06T09:21:08Z

MaksTsepkov: /* Общие впечатления */

Конференция SoftwarePeople 2011 7-8.04.2011. Попытка сделать отчет в реальном времени. Может, получится write only, как написали о моем отчете по ReqLabs, зато сразу. Тем более, что на 2 недели уезжаю в отпуск.

ADD-2011

2011-05-06T07:57:47Z

MaksTsepkov:

SoftwarePeople-2011 тренинг Мейдена

2011-04-25T06:31:21Z

MaksTsepkov:

Был на тренинге Нила Мейдена, который проходил в рамках Software People.

В них ссылка на сайт http://creatingminds.org/ на котором большое количество описаний различных техник и подходов креативного мышления.

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

Сначала о нем самом, часть этого он рассказывал. Нил работал в ИТ и в свое время его сильно обеспокоило, что традиционный процесс, RUP + UML, который сильно распространен, существенно сводит работу к процедурам, исключая творчество. Он убежден, что разработка в ИТ — творческий процесс, прежде всего на этапе постановок (которые он традиционно называет требованиями, хотя по форме у него не совсем оно). Соответственно, он вышел за пределы области и привлек в ИТ методы решения творческих инженерных задач, в частности Creative Problem Solving Осборна, и другие. На тренинге упоминал ТРИЗ, откуда тоже почерпнуты многие идеи. И применяет именно такой подход при сборе требований. При этом решение получается не чисто ИТ-решение, оно активно затрагивает и автоматизируемые бизнес-процессы — что вполне естественно. При этом у него большой практический опыт участия в различных больших успешных проектах, в том числе в областях, требующих крайне надежных решений, например, в софте для аэропортов и авиадиспетчеров. А еще Нил создал курс, на котором обучает студентов в City University London креативному решению проблем.

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

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

Техники креативных решений в ИТ классифицировала Boden (подробности). Различают:
- Трансформация границ проекта — снятие и изменение ограничений
- Техника обмена и передачи идей
- Техника исследования требований
Новизна идеи — относительно формализованное понятие, есть классификации. Определение Ritchie через семантическую непохожесть, и ее можно измерять (проект).
Поиск креативных решений — индивидуален.
Есть коллективные формы с передачей. Например, когда бизнес-специалисты осознают абстрактные ИТ-концепции так, что применяют их в своей предметке, получая принципиально новые выводы — такая передача креативной эстафеты.
Заказчику надо предлагать идеи. Можно воровать чужие — если вы способны понять чужую идею настолько, что можете ее воплотить — тоже неплохо.
Задача — всегда поиск баланса между противоречащими функциями, например, мотор — легкий, но мощный и прочный.
Ключевая практика — RESQUE Creative Workshop.
- Можно прочитать pdf. Она — авторская. На входе имеем текущее состояние + желаемое будущее + технические ограничения, на выходе — иерархический список usecase и storyboard для ключевых usecase. Usecase — достаточно общий, это некоторая относительно длинная история.
- Важная часть — комната для Workshop. Она содержит много больших рабочих поверхностей — доски для рисования и прикалывания бумажек, большой, до 6 м, стол (storyboard). Правильно, чтобы все материалы можно было окинуть взглядом одновременно, взять для изучения некоторую комбинацию — это дает неожиданные идеи.
- Что есть storyboard? Это графически организованное изложение usecase. Usecase напоминают истории, и в этом — секрет успеха. А графическое изображение будит фантазию. Usecase рассказывается в 6-9 кадров с подписями (техника сценария фильма).
- Визуальный образ, метафора должна быть неоднородной — диаграммы в стандартной нотации способствуют креативности куда меньше.
- Типовой workshop — 2 дня. Каждый день — 4 этапа в результате оформляются некоторые идеи, дальше они синхронизируются между рабочими группами и процесс повторяется. Группы работают в одной комнате, большое пространство. Если есть возможность, полезно запускать 2 группы по одной проблеме параллельно, с синхронизацией в конце дня.
- Полезны 2 фасилитатора: один помогает группам оперативно, а другой — отслеживает ход обсуждений в целом. Часто появляются неожиданные повороты, надо их засечь и оперативно скорректировать план.
- Workshop может не дать идей, это тоже результат — с большой вероятностью проблема объективна и с ней стоит смириться.
Мощная техника — решение по аналогии. Берут другую область как шаблон, строят параллели, формулируют аналогичное решение в исследуемой области и дальше с ним работают. Для авиаперевозок использовали опыт ЖД-перевозок, а еще аналогию переговорного контракта, где предметом был коридор полета. А еще — интеллектуальные шоссе и дорожные знаки. И это позволило найти новые для специалистов решения. Шаблон должен быть элегантным — простым, но работающим.
Техника построения креативных метафор и образов — потребовать сделать их на основе заданных изобразительных средств. Например, брали набор иллюстрированных журналов и задание — описать процесс образами из них (что попалось). Это снимает с привычных рельсов. Следующий этап — еще и вбрасывать картинки по одной после первой версии.
Мозговой штурм по ограничениям.
- Выявить их, особенно неявные
- Работать с каждым — а если его нет, а если его ослабить, а если взглянуть по-другому.
- Пример. Задача — снизить шум аэропорта. Реально можно сделать его предсказуемым для жителей окрестных домов, и перераспредлив, уменьшив ночью. Это проще, чем вообще снизить, а эффект достаточно велик.
В творческом процессе есть нечто такое, что удаляет конфликты (при правильной модерации). Был опыт, когда конкурирующие поставщики по 10 минут представляли каждый свое решение, а потом все вместе брайнстормили вместе с заказчиком, получая интегрированную конструкцию.
Понятно, что процесс дорогой. И только 20 % идей оказываются реализуемыми. Для важных проблем — оно того стоит.
Методы поиска решений
- Explore — поиск решения по определенным правилам и процедурам
- Combine — комбинирование известного, аналогии
- Transition — изменение условий задачи, исследование альтернативных парадигм.
Техника поиска новых решений, реализаций. Сначала генерация идей движения к некоторым обобщенным цели (trigger), достижение которых обычно уместно и позитивно в ИТ (информация и возможность выбора, коммуникации, доверие, удобство, экология, сервис, соучастие). Потом — выбор основных, и комбинация их в некоторые сценарии, с привлечением других. Дальше — ояценка полученных сценариев…
Как заставить порождать идеи? Можно просто обязать сделать комбинацию из заданных. Пример такой комбинации — заказ массажиста на борту самолета — сейчас практикуется некоторыми компаниями, пользуется спросом.
У них есть online библиотека методов организации поиска креативных решений в разных ситуациях (под разные форматы, с разными затратами). Обещал прислать ссылку.
Есть софт, поддерживающий эти процессы в той или иной мере. Для распределенных мозговых штурмов и для интерактивного рисования, комбинирования картинок. Правда, быстрый поиск по тому, что записал ничего не дал — подождем презентации.
Фотографировать доски надо, но это замораживает овеществленную идею. Лучше рисовать электронно, если получается сохранить интерактив.

Мои мысли по ходу тренинга

Новации от Apple типа iPhone и iPad — во многом комбинация известного. Просто в этих продуктах точка баланса между техническими возможностями смещена в нестандартную область. Например, iPad — взяли электронную книгу и превратили в комп «насколько возможно», в частности обеспечив относительно полноценный инет — на уровне мобильника с большим экраном. Технически, думаю, это могли сделать многие фирмы, но идеи, что такой продукт будет востребован — не было. В этом — суть многих креативных решений, они — нестандартная комбинация известных вещей, которая удачна.
Относительно методики Нила, мы очень быстро переходим от «Что» к «Как» — мы строим модель и погружаем в нее заказчика. Но в рамках модели — ищем решение креативно.
Методы Стаса по интерактиву в разных формах с сохранением результатов — очень актуально в рамках поиска креативных решений.

Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011)

2011-04-17T14:18:46Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Доклад на AgileDays-2011 4-5.03.2011
Видео https://vimeo.com/22491199

ReqLabs-2011

2011-04-08T18:44:00Z

MaksTsepkov: /* Горенко Ольга. Интерфейс бизнес-целей */

AgileDays-2011 - тренинг Книберга

2011-03-13T19:02:24Z

MaksTsepkov:

На конференцию AgileDays-2011 приезжал Henrik Kniberg, который 2 дня перед началом конференции проводил тренинг по Agile, кстати, слайды с тренинга лежат у него на сайте. Я на тренинге был, вынес много полезного и хочу поделиться впечатлениями.

Отчет в блоге день первый и день второй

Учетная машина (Максим Цепков на ADD-2010)

2010-12-24T17:44:59Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Учетная машина — универсальная архитектура учетно-аналитических систем

Программа конференции
страничка доклада на сайте конференции

SECR-2010

2010-12-21T16:35:43Z

MaksTsepkov: Массовая правка: замена Категория:Конференции на Категория:SECR

ADD-2010

2010-12-07T20:50:59Z

MaksTsepkov: /* Антон Овчинников. Деньги и внутренние часы разработчика */

Конференция Управление знаниями - 10.2010

2010-11-12T15:32:09Z

MaksTsepkov: MaksTsepkov переименовал страницу Конференция Управление знаниями - 10.2010 в KM Russia-2010 - конференция по Управлению знаниями

Учет ценных бумаг - сделать сложное простым (Цепков на SECR-2010)

2010-10-19T12:23:57Z

MaksTsepkov: Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}

Еще про архитектуру

Доклад был сделан на банковской секции конференции SECR-2010

Презентация выложена на slideshare

Докладчик: Максим Цепков, главный архитектор компании CUSTIS (Заказные ИнформСистемы)

Название доклада: Учет ценных бумаг - сделать сложное простым (Securities Accounting - Make It Easy).

ЛАФ-2010

2010-08-02T11:51:24Z

StasFomin: /* Общее впечатление */

Лучше один раз увидеть

2010-03-19T15:09:46Z

MaksTsepkov: Массовая правка: добавление Категория:Диаграммы учета

Максим Цепков - главный архитектор компании CustIS (Заказные ИнформСистемы)

Опубликовано в журнале Intelligent Enterprise, № 2(февраль), 2010 ^[1]

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

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

↑ Intelligent Enterprise, № 2 (212), 22 февраля 2010 года

Путь к результативной автоматизации

2010-03-09T14:50:32Z

MaksTsepkov: MaksTsepkov переименовал страницу Путь к результативной автоматизации в [[Путь к результативной автоматизации (Директор информационной слу…

Максим Цепков главный архитектор компании CustIS (Заказные ИнформСистемы)

Опубликовано в журнале «Директор информационной службы» №10-2009 ^[1].

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

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

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

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

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

Рассмотрим каждый из этих шагов подробно и с примерами.

Оценивать бизнес-модели, а не функционал

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

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

Оценка системы на основе функционала приводит к ошибочному решению. Почему же она так распространена?

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

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

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

Мы считаем, что бизнес-процессы любой компании специфичны е, поэтому их анализ и соотнесение с новой информационной системой так важен.

Получение бизнес-модели системы

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

Первая причина отсутствия описания бизнес-модели — его большая сложность.

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

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

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

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

Что входит в описание бизнес-модели

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

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

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

Получение бизнес-модели по публичным материалам

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

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

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

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

Получение бизнес-модели от поставщика

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

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

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

Оценка бизнес-процессов компании в системе

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

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

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

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

В результате оценки все бизнес-процессы разбиваются по трем категориям:

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

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

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

План изменения бизнес-процессов

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

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

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

Далее приведено несколько примеров решения подобных задач, позволяющих компании приспособиться к системе.

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

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

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

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

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

Решение. В заказе вместо конкретных артикулов используются «обобщенные комплектующие». Приход товара осуществляется на отдельный логический склад, и специальный обработчик автоматически проводит резервирование с учетом замен, а остальной товар переводит в свободный доступ.

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

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

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

Максим Цепков — главный архитектор компании «Заказные ИнформСистемы» (CustIS); M_Tsepkov@custis.ru

↑ «Путь к результативной автоматизации», Директор информационной службы, №10-2009 http://www.osp.ru/text/print/302/10361605.html

Результативность автоматизации

2010-02-11T17:35:44Z

MaksTsepkov: MaksTsepkov переименовал страницу Результативность автоматизации в Результативность автоматизации (Директор информационной службы 7-2009)…

Максим Цепков - главный архитектор компании CustIS (Заказные ИнформСистемы)

Журнал Директор информационной службы (CIO.RU), № 7, 15 июля 2009, стр. 40-42.

Высказывание Бернарда Шоу: «Постарайтесь получить то, что хотите, или же вы будете вынуждены захотеть то, что получили» — хорошо иллюстрирует часто встречающийся и не слишком радужный результат автоматизации, когда внедрена некоторая информационная система, к которой компания вынуждена приспосабливаться. Как избежать такого результата и получить внедрение, нужное бизнесу?

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

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

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

ArchLabs-2009

2010-01-13T20:24:23Z

StasFomin: оформление, орфография/пунктуация