Отправляет email-рассылки с помощью сервиса Sendsay

Бизнес-программирование

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 44 RSS
←   Октябрь 2018   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
09.10.2018
09:13:37
09:14:19
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Сайт рассылки: https://business-programming.ru
Открыта: 08-08-2018

Автор
Иван Белокаменцев

Статистика

44 подписчиков
0 за неделю
←   Все выпуски   →

Бизнес-программирование: Конфликт 'один - много'


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

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

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

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

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

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

Второй процесс выполняется каждый день, и не один раз. У него – много экземпляров каждый день. Экземпляром является заявка на закуп. Зачем «рисователь» процесса объединил эти действия в один процесс? Да Бог его знает. Вероятно, хотел побыстрее отделаться, закрыть задачу по разработке процесса, и, возможно, получить свою премию.

Ну, вроде бы, какая разница? Все же – адекватные люди, и понимают, что процесс нарисован «просто так», а жизнь идет по своим правилам. Тогда зачем рисовать такой процесс? Так и порождаются тонны бумаги, которой никто потом не пользуется.

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

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

А «рисователь» процесса хочет, чтобы у него получилось красиво: вот заявка, вот действие над заявкой, вот время выполнения процесса. Его волнует только внутренняя логика и непротиворечивость процесса.

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

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

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

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

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

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

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

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

Если вы – программист, то сталкивались с подобным положением дел. Заказали вам автоматизацию – ну, я не знаю, заявок на ремонт оборудования. Вы все сделали, программа получилась красивая и удобная, вы ее проверили, отладили, протестировали. А заказчик не пользуется. В системе лежит одна заявка на ремонт – тестовая, которую вводили вы.

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

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

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