Привет, я Алекс Степанов – независимый разработчик бизнес-приложений. В настоящее время я также сотрудничаю в роли ИТ-аналитика с топовой федеральной розничной сетью и консультирую их ИТ-менеджеров по технологиям интеграции и функциональной разработки, написанию ТЗ. Но то, о чём я сообщу далее, было получено мною задолго до этого сотрудничества.
Если вам приходилось проектировать ИТ-решения для бизнеса, то никогда не задавались такими вопросами? - Конечно ли вообще пространство вариантов создаваемых ИТ-решений? - И если да, то что определяет границы этого пространства? - И из каких областей, это пространство может состоять? Или говоря другими словами: то, что нашей проектной команде предстоит сделать, имеет вообще объективные разумные границы и счетное количество вариантов реализации? Эти вопросы и ответы на них отделяют ИТ, как ремесло и бизнес, от ИТ, как инженерия и наука. В данной статье я решил поделить с вами некоторой частью своей системы знаний…
Когда я участвовал в проектах разработки, внедрения и сопровождения бизнес-приложений в роли консультанта, аналитика/проектировщика, программиста/кодера и даже специалиста техподдержки, то часто чувствовал дискомфорт, связанный со множеством проектных и технических неопределенностей. В основном это происходило на этапе обработки исходных требований и формирования замысла (образа) ИТ-решения и на этапе его проектирования. Это самые ответственные этапы, ошибка на которых может привести к кратному превышению затрат и времени ИТ-проекта. Корень этих неопределенностей в том, что понять, чего на самом деле хотят бизнес-заказчики часто непросто, а не поняв это достаточно глубоко, возникает целое поле альтернатив, выбрать из которого что-то одно наиболее подходящее еще сложнее.
Высокий уровень ответственности в условиях неопределенности и связанный с этим дискомфорт возникает не из-за того, что вы не имеете четкого плана разработки ИТ-решения – это как раз и есть творческая составляющая профессии («в этом вся соль»), а осознание того, что «мы – заказчик и исполнитель, выбираем единственный путь, но даже не знаем из потенциально какого числа». И вот в какой-то момент я начал искать основу, на которую можно было бы опереться – своего рода парадигму, в рамках которой можно было бы ставить вопросы, применять методы поиска и находить обоснованные решения. Таким образом владеть проектной ситуацией, а как следствие, снизить уровень того самого дискомфорта. И в конечном быть лидером, а не пассивным исполнителем, ведомым неизвестно куда.
От личной мотивации теперь перейдем к проблеме и инструменту. Итак, перед нами задача на разработку бизнес-приложения (а точнее, пока лишь нечетко сформулированная потребность заказчика), и вместе с ней у нас появляются вопросы типа таких: «о каком типе приложения идет речь?», «чем оно будет управлять?», «что пользователям нашего приложения понадобится завтра?», «какие функциональные модули, расширяющие функциональность приложения, нам вероятно придется делать в будущем?», «какая архитектура/структура/паттерны/платформа нам нужна, чтобы все создаваемые в будущем функциональные модули/функции/«фичи» гармонично интегрировались друг с другом?». Как правило, заказчик может сказать вам только про «вчера» и «сегодня». И если вы не будете задаваться похожими вопросами, вы, во-первых, скорее всего сделаете ИТ-решение для «вчера» (к моменту релиза или внедрения «сегодня» точно превратится во «вчера» или «позавчера»), а во-вторых, это будет «одноразовое» приложение, в том смысле, что его придется переделывать, и если не вскорости, то немного погодя, когда будут создаваться дополнения/расширения/новые модули. Я видел много примеров типа «давай лепить то, что нужно сейчас, а потом видно будет», и вот это «слепленное» потом многократно «перелепливается» и доходит до точки невозможного – «нам нужно больше времени, нам нужно больше программистов, нам нужно больше…, больше…, больше…», потом коллапс, и народ разбегается на «новые и хорошо оплачиваемые» проекты. А если коллапс и не наступает, то у построенных таким образом ИТ-решений все равно часто нелегкая судьба в плане их эксплуатации и развития, а вернее, у тех, кому приходится дальше эти решения поддерживать – их стихийно-случайный и ситуативный «жизненный цикл».
Поэтому возможность прогнозировать вероятные направления развития ИТ-решения является ценностью. Особенно если оно строится на объективной основе, а не на мнениях. Это и есть отправная точка для «software engineering».
По мере накопления практики я стал замечать «управленческую» ограниченность (в определяемом далее смысле) вариантов целевых/первичных бизнес-систем – говоря языком кибернетики, объектов управления – функциональных областей, таких как управление финансами, транспортная логистика, производство и хранение товаров, управление персоналом и т.д. Исходя из этого я пытался обнаружить и ограниченность «целесообразных» вариантов обслуживающих/поддерживающих их ИТ-решений; ведь любые бизнес-приложения – суть поддерживающие соответствующую область бизнеса и подчиненные ее целям информационные инструменты/системы. В качестве примера ИТ-решений приведем системы класса MRP/CRP, WMS, CRM/SRM, ERP и т.д.
Хотя для одной и той же целевой системы (управляемого бизнес-объекта/процесса) можно создать произвольное количество формальных вариантов реализаций (экземпляров) ИТ-решений, просто меняя их исходный программный код, эти варианты с точки зрения некого стратегического управления разработкой ПО будут являться тавтологиями. Существенные и ценные вариации, как то алгоритмы расчетов (например, оптимизации планов), также можно рассматривать как отличия ИТ-решений в отдельных компонентах, и с нашей «разрешающей способностью» в данном контексте «не видны» (ИТ-решение, как образно говоря, «агрегат», остается тем же, но с замененной «деталью»). Принципиальным различием в вариантах ИТ-решения являются их информационные сущности (объекты модели), которыми они оперируют, и логика операций над ними (последовательность и правила обработки данных).
Выбранный вариант, является «скелетом» ИТ-решения и определяет всю его дальнейшую «судьбу», так как фиксирует его основные возможности и определяет область применения, приводит к достаточности или ограниченности его применения в будущем, закладывает необходимость переделки или безальтернативность разработки нового ИТ-решения и т.д. Как было сказано вначале, отсутствие стратегического видения (его невозможности) приводит к созданию «одноразового» ИТ-решения, жизненным циклом которого сложно, а, следовательно, дорого управлять.
В своей работе я основываюсь на стандарт ISO/IEC 15288 (ГОСТ Р ИСО/МЭК 15288). Понимание стандарта в данном контексте: создание и развитие любой искусственной системы сводится к управлению тридцатью (в последней редакции стандарта) процессами жизненного цикла (ЖЦ) систем. Хотя у нас нет ничего, что подтверждало бы ограниченность вариантов целевых (предметных) систем, но благодаря стандарту есть уверенность, что любая из них будет представлена (воплощена) в той или иной комбинации процессов ЖЦ систем. Таким образом, полагая, что ИТ-решения являются вспомогательными по отношению к целевым и призваны повышать эффективность их ЖЦ, то можно считать, что любое создаваемое и развиваемое ИТ-решение - это инструмент для повышения эффективности управления процессами ЖЦ целевых систем. Известно количество этих процессов, описана деятельность и результаты каждого из них.
Повторю еще раз, это тонкий ключевой момент: «я не знаю точную конфигурацию бизнес-системы для которой строю свое ИТ-решение, но я знаю, что любая бизнес-система управляется на основе не более, чем тридцати уже известных процессов ее жизненного цикла, значит, любое создаваемое приложение – это инструмент для управления какой-то комбинацией этих процессов». А в этих процессах ЖЦ я уже хорошо разбираюсь (моя трудовая книжка уже в трех томах и пока нет признаков, что не добавятся новые вкладыши). И у меня уже есть высокоуровневые паттерны разработки для каждого из этих процессов (или «паттерн для разработки паттернов»).
Таким образом, я предлагаю методически сводить разработку ИТ-решений не к разработке программных приложений, поддерживающих частные случаи (варианты) целевых систем/объектов управления (представление о которых, как было отмечено выше, на практике всегда сильно «зашумлено» и неполно), а к разработке ИТ-решений для поддержки процессов ЖЦ целевых систем. Независимо от имеющихся ресурсов, краткосрочных проектных целей, проектных методологий и технологий разработки, у лица, контролирующего ЖЦ ИТ-решения будет инвариантная методология для понимания предельных границ развития ИТ-решения и управления промежуточными этапами этого развития.
Ниже несколько слайдов для предлагаемой концепции (из моих выступлений). Эти иллюстрации для своего рода «макро-ИТ-решений», но парадигма распространяется и на любые «малые» бизнес-приложения.
Вы можете написать мне по адресу: erpacademy.ru@gmail.com
Комментарии (21)
0pauc0
09.04.2024 09:53А так, для общего развития, напишите (укажите ссылку) определения понятий "бизнес-система", "бизнес-приложение".
Только не говорите, что это и ежу известно.
После того, как определите термины, можно и подискутировать по делу.
erpacademy Автор
09.04.2024 09:53Бизнес-система - предприятие или структурное подразделение предприятия; включает комбинацию ресурсов (людских, технологических, финансовых и др.); процессы системы располагаются в доменах управление активами, цепочки поставок, производство, жизненный цикл продуктов и услуг и др. Это всё. Для краткости: бизнес-система = предприятие (enterprise) или его часть.
Бизнес-приложение - ИТ-решение для управления (анализ, прогнозирование, планирование, учёт/мониторинг/контроль) бизнес-системой.
0pauc0
09.04.2024 09:53бизнес-система = предприятие (enterprise) или его часть
Во-первых. Если бизнес-система это предприятие, то почему бы и не применять по тексту это известное, общедоступное слово.
Во-вторых. Ваше определение бизнес-системы еще где-то можно увидеть? Даже в инфопомойке под названием википедия "бизнес-система" и "бизнес-приложение" не присутствуют.
В-третьих. Предприятие может выполнять некоммерческую деятельность, то есть не извлекать прибыль из своей деятельности, еще проще - это не бизнес, а государственная функция или задание, а может и благотворительность. Как быть в этом случае с таким предприятием, оно выпадает из вашей логики?
В четвертых. За "бизнес-приложение" вообще ничего не пояснили.
Кроме этого, красивые слова "жизненный цикл продуктов" также требуют разъяснения, что имеется ввиду? Есть понятное для всех определение?
Не издеваюсь, не докапываюсь. Если что-то обсуждать или воспринимать, то нужны термины, которые однозначно описывают предмет.
erpacademy Автор
09.04.2024 09:53Даже в инфопомойке под названием википедия "бизнес-система" и "бизнес-приложение" не присутствуют.
Википедия - это величайшее изобретение и достижение человечества. (Да, знаю одного плешивого, который когда-то сказал, что Интернет - это помойка; видимо, ничего типа порно он там не искал и не хотел. Ну да ладно, зачем нам это обсуждать.)
Что касается определения терминов: мне был задан вопрос, как автор статьи я дал ответ. Ответ вполне нормальный. К сожалению, страсть к ссылкам удовлетворить не могу - к моему мозгу подключиться не получится.
почему бы и не применять по тексту это известное, общедоступное слово
Ответ очевиден: чтобы не писать каждый раз "предприятие (enterprise) или его часть".
... может выполнять некоммерческую деятельность... Как быть в этом случае с таким предприятием...
Специально дал перечень нескольких доменов (предметных областей). Если "такое предприятие" их имеет, то "из логики не выпадает". Да - и государственные предприятия, и некоммерческие предприятия - это тоже про экономику и это тоже "бизнес"...
За "бизнес-приложение" вообще ничего не пояснили.
Повторяю (от общего к частному): ИТ-система -> ИТ-решение (прикладной / предметно-ориентированный уровень ИТ-системы) -> Бизнес-приложение (ИТ-решение для управления бизнес-системой - ИТ-система для предметной области "управление предприятием"). Доступнее не могу, пардон.
слова "жизненный цикл продуктов" также требуют разъяснения
Домен бизнеса, включающий проектирование продукта, его сопровождение и обслуживание (включая процессы CRM). Вот, картиночкой своей поделюсь для наглядности:
Все, пардон, больше нет возможности в терминах разбираться.
0pauc0
09.04.2024 09:53Все, пардон, больше нет возможности в терминах разбираться.
Так вы и не расшифровали термины, больше того - добавили новых непонятных (государственные предприятия, домены структуры предприятия).
Ладно.
В связи с этим последний вопрос, что в вашей модели есть бизнес? Может отсюда начать.
erpacademy Автор
09.04.2024 09:53Тогда мы выйдем на тему паттернов проектирования (в процессах ЖЦ целевой системы, т.е. бизнес-системы). А это пока не входит в мои планы.
0pauc0
09.04.2024 09:53Тогда к чему вы все это здесь написали, если не хотите/не можете определить что такое бизнес. Гадать предлагаете, что вы имели ввиду?
erpacademy Автор
09.04.2024 09:53Ок, можем определить бизнес как управление бизнес-процессами. Или как управление процессами ЖЦ бизнес-системы (предприятия), и таким образом классифицировать их (т.е. бизнес-процессы внутри процессов ЖЦ).
Чтобы продолжать дискуссию, мне нужно понять её конечную цель. Если просто разобраться в терминах и понятиях, то пока остановимся.
erpacademy Автор
09.04.2024 09:53К редакции/администрации Хабра: вижу в оценках "минус" из-за несоответствия статьи тематике сайта; чудно, однако - если концепции проектирования ИТ-решений, опубликованные как мнения, не по тематике (хотя чего я только здесь ни читал) - т.е. если "минус" такого типа не будет аннулирован модератором, то это моя последняя публикация на этом ресурсе.
TimKady
09.04.2024 09:53Дисклеймер: перед тем, как начать хотел бы отметить, что мои замечания и критика носят исключительно конструктивный характер. Мои слова не имеют цели кого-либо обидеть или подвергнуть сомнению профессионализм автора оригинальной статьи. Я глубоко уважаю труд коллеги и его стремление к инновациям и улучшениям в области ИТ. Моя цель — поделиться собственными наблюдениями и опытом, которые, как мне кажется, могут способствовать более глубокому пониманию темы и, возможно, сэкономить время и ресурсы автора в будущих разработках. Также прошу простить за объемность текста ниже.
Попытка создать универсальные ИТ-решения, подходящие для любого типа бизнес-процессов, кажется заманчивой, но для ее реализации недостаточно знаний жизненного цикла технических систем и опыта инженера-разработчика (простите). Подход к проектированию ИТ-решений, описанный в статье, хоть и не лишен смысла, содержит в себе рациональное зерно, но в целом является излишне упрощенным в отношении управления бизнес-системами. Управление бизнесом — это не столько вопрос оптимизации процессов, сколько управление динамикой и взаимодействием между различными объектами управления в условиях неопределенности и ресурсных ограничений. Судите сами!
Во-первых, бизнес, как систему, образуют объекты управления. И бизнес-процессы – это действия, в результате которых мы ходим управлять этими объектами – привести и удерживать каждый объект управления в нужном состоянии. Например, потенциальный потребитель должен быть приведен в состояние, в котором он готов совершить покупку. А новый станок должен быть приведен в состояние, в котором он может быть пригоден в технологическом процессе. Именно этот цикл и описывает стандарт ISO/IEC 15288 (не стоит приводить в нормальном контексте ГОСТ –работа плохих переводчиков-копипастеров собой смысла). Правда у меня получилось гораздо лучше, как мне кажется, систематизировать этот цикл, разделив его на фазы: инициации, адаптации (локализации), рабочую фазу, фазу оценки, воспроизводства и завершения. Это позволило корректно расширить подход на все объекты управления. Ну что сказать, институт стандартизации (ISO) уже не тот. Но на этом все рациональное в вашей работе заканчивается. Простите, ничего личного!
Когда вы пишите, что собираетесь управлять тридцатью процессами, я задаю простой вопрос: а на каком уровне (декомпозиции). Если мы про 1-й уровень, то их 10 – по одному процессу на каждый объект управления, составляющих бизнес-систему (да, у любого бизнеса их набор одинаков, интуиция вас не подвела). На следующем (состояния этих объектов) их уже 60. А вот на уровне блоков работ… нужно как-нибудь более точно посчитать, но примерно 360-400. Кстати, отсутствие той самой системности, о которой пишут разработчики стандарта ISO/IEC 15288 не позволили корректно отнести процессы к тому или иному уровню – на одном мы меняем само состояние, а на другом – параметр или характеристику объекта управления. Но это уже детали.
Во-вторых, бизнес не был бы системой, если бы был простым набором (множеством, сетом) объектов управления. Свойства, отсутствующие у исходных объектов, привносит в бизнес взаимодействие этих объектов. А вот это уже большая и не понимаемая многими – не только ИТ-специалистами, не только менеджерами, но академическими работниками. Увы.
А вот здесь начинается сложности. Например, сама постановка задачи – в чем состоит управление? Получение прибыли? Абсолютно неверно! Достижение стратегических целей? Почти, но не в этом, всё сложнее. Управление состоит в поиске баланса между текущей эффективностью и результативностью (способностью достигать поставленные цели) системы в условиях неопределенности и наличия ограничений на используемые (доступные) ресурсы. Откуда баланс? Дело в том, что увеличение эффективности снижает результативность! Последняя требует некоторой избыточности – дублирования, резервирования, запасов. Но желание повысить результативность неизбежно снижает эффективность.
Путь, предложенный вами, кажется мне важным шагом в поиске методологии проектирования ИТ-решений, которые могут прийти на смену «менеджменту кожаных мешков». Однако, важно подчеркнуть, что успех такой системы зависит не только от следования стандартам (вернее, совсем не в этом) и отдельным методологиям, но и от глубокого понимания природы бизнеса. Думаю, что мои замечания помогут вам доработать подход, основанный на ISO/IEC 15288, в сторону большей системности и всеобщности. Будут вопросы – пишите, готов помочь, объяснить, подсказать – к схожим с вашими мыслям я пришел 25 лет назад. :-)
Успехов!
erpacademy Автор
09.04.2024 09:53Для тех, кто будет читать все эти комментарии под статьей, повторю: я говорил не о создании ИТ-систем (обеспечивающих целевую, т.е. бизнес-систему) на основе процессов их ЖЦ, а о взгляде на любую задачу проектирования ИТ-системы, как задачу проектирования инструмента для управления выделенной комбинацией процессов ЖЦ бизнес-системы (из 30 известных человечеству и отраженных в ИСО 15288). Второй частью системы знаний /методологии является уже опыт (паттерн) проектирования под каждый из этих процессов. Об этом я ничего пока не говорил. Но для начала и первой части достаточно: ИТ-аналитик может познакомиться с каждым процессом самостоятельно и начать думать и обеспечивать себе проектное лидерство в каждом из них. Так я работаю.
Ну а что касается "бизнес - это что-то такое неуловимое, не инженерное, не доступное формальным ИТ-системам, не автоматизируемое как в мире АСУТП", то это просто частное и не доказываемое утверждение - имеет право на существование, но не более. Но мы видим, что практика это постепенно опровергает - как пример, e-commerce.
TimKady
09.04.2024 09:53:-) Спасибо за ваш ответ!
К сожалению, я наверное плохо объяснил. Попробую еще раз, кратко и более доступно:15288 описывает отдельные подсистемы, а не систему целиком. Поэтому область его применения - не вся система, а отдельные подсистемы (базовые, ключевые объекты управления). Но "собака роется" в другом месте – на уровень выше во взаимодействии этих объектов.
"из 30 известных человечеству" – право, не стоит отождествлять ISO со всем человечеством, тем более, что их стандарты часто не только не являются эталоном знаний, но бывают далекими от практики и разумности.
опыт (паттерн) проектирования – да, вы правы, я с этим и не спорил. Я вообще не спорил, а указывал на методические недочеты того, о чём вы (подчеркиваю, не я) писали. Об этом можете говорить, можете не говорить – это ваше дело. Для меня это очевидно, более того, воплощено в виде соответствующих методик, а сейчас воплощается в софте (комбинация AI, который синтезирует цепочки действий при отсутствии их в опыте, и системы, извлекающей соответствующие сценарии при их наличии).
"ИТ-аналитик может познакомиться с каждым процессом самостоятельно и начать думать" – я тоже так думал 30 лет назад. Но для 95% популяции думать больно и приходится думать за них, предоставляя пошаговые решения. Увы. Так я и работаю. :-)
"бизнес - это что-то такое неуловимое" – не могли бы вы указать, процитировать, если это вас не затруднит, где я писал такое! Опять же, раз вы так поняли, наверное, это я плохо объяснил: всё это уловимо, и более того, сейчас я реализую проект уровня AGI-системы, которая именно и решает, сформулированную мною в ответе вам, задачу. Так что не утруждайте себя доказательством этого тезиса, тем более что делаете вы это не очень убедительно (на мой скромный взгляд) :-)
И повторюсь: я даже не критикую, я даю подсказки, так как прошел этот путь четверть века назад. Можете их отбросить, можете задуматься (я вижу, что вы это можете делать), но проявляйте меньше экспрессии – если кто-то чего-то не понял, это не они плохие, это мы плохо объяснили.
Успехов!
erpacademy Автор
09.04.2024 09:53Спасибо! Выхожу из этой ветки дискуссии.
Но только один маленький момент (не могу не отметить) про:
15288 описывает отдельные подсистемы, а не систему целиком.15288 описывает СИСТЕМУ ЦЕЛИКОМ.
TimKady
09.04.2024 09:53Для вас это категория веры, а для меня – знаний. Просто перечитайте стандарт и ответьте себе (!) на вопросы:
В каком месте стандарта описывается взаимодействие объектов управления, каким образом? Как это взаимодействие порождает эмерджентность бизнеса, как системы? В какой форме?
Подходит ли описанный в стандарте "жизненный цикл" для описания и прогнозирования поведения (развития) бизнеса в целом – от бизнес-идеи до системы управления знаниями?
Ответив, вы увидите, что сейчас вы заблуждаетесь. Но! Вы имеете на это право! Как говорится, я сделал всё, что мог! :-)
Всего доброго!
avf48
В общем, мысли то верные, но
Стандарт то, кем написан? Вами?? А остальные тогда где?
А ничего, что есть новая версия стандарта ГОСТ Р 57193-2016? К тому же, 12207 и 15504 описывают ЖЦ именно для ИТ систем, а не только в общем... Для бизнес систем вы забыли исо 9001, а для архитектуры 19439...
А в стандарт лень было заглянуть? или вы считайте, что все кроме вас дураки? Какие б' "высокоуровневые паттерны", что это вообще? Есть стандарт.
Какой смысл в классификации ИТ систем (MRP, ERP, APS...), если микросервисная архитектура эффективнее. Такое чувство, что статья из 2005 года...
стандарты
erpacademy Автор
Увидел в комментарии выше упоминание ИСО 9001, окончательно понял, что не вопрос, а каша (прошу прощения). И про ИСО 12207 здесь не к месту, так как про процессы ЖЦ самих ИТ-решений я ничего не говорил (да, это смежная тема, но статья не об этом). Не могу отвечать на все и сразу. Можете задать один самый важный для вас вопрос, я отвечу.
avf48
Выбирайте:
Почему используйте не актуальную версию стандарта? (для прим: процессы проекта были расписаны более подробно в в серии "Проектный менеджмент")
Зачем использовать MRP, ERP итд? 15288 (57193) и 57195 разве не описывает процессы ЖЦ в общем для системы?
Можете пояснить, что в ИСО 9001 такого страшного? Или есть более "высокоуровневый" стандарт, для руководителей, по достижению качества...
*Про правильное применение стандарта я молчу... сертификат - не гарантия качества!
Не дуйтесь... Как специалисты обращаются со стандартами, так и я с ними))) Правила культурного общения, нормы поведения, уважение... это же просто слова... а буква "Б", это просто буква "Б"...
erpacademy Автор
Толку для данной темы никакого. На нем ничего не спроектируешь. Это только для одного из 30 (24) процессов ЖЦ из 15288.
И цикл PDCA - здесь бесполезен. Есть только один цикл по которому живут и работают все системы: прогнозирование -> планирование -> выполнение (учёт /контроль /мониторинг) -> анализ.
erpacademy Автор
Для примера предложенной мною концепции. Что даже такие мастодонты развиваются так, как описано - ассимилируя в себя процессы ЖЦ целевых бизнес-систем (предприятий).
А раз они так, то и "малюсенькие" бизнес-приложения уровня "три кнопки" только так и будут.
erpacademy Автор
Какого - 15288? (о других я не упоминал) Потому что на русском новую версию - с 30 процессами ЖЦ получить нельзя. А я для кого писал? Для тех, кто русский Хабр читает. Но и 24 процессов им пока вполне хватит, пока свои паттерны проектирования для каждого придумывать будут. (может, я отстал от жизни - и уже опубликовали гостовский клон?)
erpacademy Автор
Добавлю вот что: если все-таки надумаешь задать умный вопрос, то не ставь как выше в "... Какие б' ... " свое б'. Прибереги его для других, для своих стандартов общения.