Комментарии 17
Зашёл почитать про что-то типа dbt :) А тут...
все бизнес-сущности можно разделить на шесть категорий: …
Самое главное не указали - время, timeline. Без него шесть указанных вами составляющих - всего лишь статичные картинки.
Event - это как раз про время, оставила классическое название от Захмана. В работе - да, там везде Time использую для очевидности. Если на сам Фреймворк посмотреть, то видно, что рядом с Event стоит вопрос "когда?"
Не то. Время в смысле не просто время и дата. Если по обывательски попробовать - указанные вами шесть составляющих не обладают присущей только времени особенностью - необратимость вкупе с нулевой эластичностью.
Все дела и изменения (вы называете их бизнес-процессами) могут быть либо в прошлом либо в будущем. О настоящем возможно говорить только применительно к минимальному временнОму интервалу, который вы задали для своих преобразований. Может часы, а может и пикосекунды.
Можно растянуть/сжать событие, изменив его начало и/или окончание, но если оно прошло заданный минимальный временнОй интервал настоящего, то оно просто остается на временнОй оси в прошлом в том виде, в каком состоялось в момент тика настоящего.
Операций множество, пространств не меньше, и все они проецируются на одну единственную временнУю ось, с разными интервалами планирования, исполнения, контроля, анализа и даже целеполагания. Вырвать из всего этого покупку товара конечно можно, но только в статике, в виде слепка прошлого. Потому что если говорить о будущей покупке, то она может быть разрушена кучей дел и изменений, о которых вы даже не подозреваете. А фреймворк тем более.
Постарался как-то на коленке донести, без умных слов специальных терминов и философии.
Именно поэтому Время фиксируется некими событийными фактами - или в прошлом или в будущем.
Конечно, мы не можем "поймать время за хвост", но описать будущие или свершившиеся факты через статусные или событийные модели - вполне себе в состоянии.
Что же вам всё таки смущает? Тот факт, что мы каким-то образом пытаемся зафиксировать или смоделировать время?
Универсальность фреймворка Захмана в том, что он схематично описывает абсолютно любую деятельность любого предприятия.
Вот это меня слегка поразило, вкупе с тем, что в модели совсем нет времени.
Что же вам всё таки смущает?
Меня уже ничего не смущает. Но, к сожалению, зафиксировать то (время), что мы даже не знаем что из себя представляет, это скажем так, слишком наивно. Не мы фиксируем время, а оно дает нам возможность планировать события в будущем, анализировать события прошедшие, присутствовать в настоящем.
Бизнес-модели и бизнес-процессы (вашими терминами) сегодня диктуются моделью экономики. А она меняется. Например последней, при которой мы живем, 80 лет. Бизнес-модели и процессы при феодальной модели экономики были совсем другие, при рабовладельческом строе бизнеса (в нынешнем понимании) вовсе не было.
Поэтому про универсальность модели Захмана можно было бы говорить в той или иной мере лишь применительно к существующей модели экономики, если бы не одно обстоятельство, на которое я пытаюсь обратить внимание, но никак простыми бытовыми словами видимо не получается.
Штука называемая Время - есть, надеюсь с этим никто не спорит. Но так как никто не знает, что это такое, подавляющее большинство моделей процессов, событий и перемен, стыдливо упускают его свойства, оперируя только датой и временем события. А эти свойства есть, сейчас мы можем назвать несколько - направленность, длительность, временнАя последовательность, и как вишенка - одновременность.
Именно свойство одновременности времени (тавтология конечно но куда деваться) опускают все виденные мной модели, которые описывают дела и изменения. Именно одновременность можно одновременно отнести и к объективной характеристике мироздания и к субъективному отражению человеческого сознания. Остальные свойства времени либо субъективны, либо объективны.
Исходя из того, что мы все таки в большей части живем как часть микромира (пределы планеты) и лишь пытаемся заглянуть в космологию и макромир, то любая модель просто обязана иметь в основе временнУю ось. Интуитивно (или неосознанно), например в базах данных временных рядов, мы обязательно ставим timestamp, а как без этого. Но это в данных, фиксирующих прошедшие события. А как быть с будущими событиями (запланированными или возможными независимо от нашей воли)? Как можно назвать timestamp будущего? Какими свойствами она должна обладать?
Не имея ответа на этот вопрос, человечество на сегодняшний день придумало множество эрзацев, ну например понятие "риск", понятие "устойчивость системы управления" и т.п.
В модели Захмана (по крайней мере в источниках которые я видел), нет ни способов математической оценки риска, ни формул оценки устойчивости системы. А раз нет этих оценок, то как можно говорить о доказанности (полностью или с определенной и достаточной вероятностью) действенности, эффективности и применимости этой модели?
Вы прекрасны! Многие знания - многие печали )
Мне кажется, что иногда не нужно пытаться объять необъятное - вселенная непредсказуема, а время быстротечно. Как бы мы ни гнались за модой, она изменится.
Я лишь пытаюсь здесь и сейчас использовать предложенную Захманом модель для нужд моделирования данных, и неплохо получается. Но, конечно, не поручусь, что спустя сотню лет эти же знания будут востребованы и применимы как прежде.
Прошу простить меня за невежество и позвольте пригласить в свой канал - @DataGovernance4all , где с удовольствием подискутирую с вами и выслушаю прочую критику к моим постам.
Это не критика вашего поста. Я всего лишь пытаюсь вас предостеречь от слов "универсально", "абсолютно любого" и им подобным. Тем более в отношении моделей, пытающихся описывать процессы в действующей в мире экономической модели, базирующейся как на воспроизводстве капитала и добавленной стоимости, так и на возможности делать деньги прямо из денег (и где хоть одно из этих слов в модели Захмана).
А она, эта действующая модель экономики, сейчас и прямо на наших глазах уверенно идет к изменению. И произойдет это еще при нашей жизни. И придумают новые модели процессов, отвергнув старые, потому что ни те ни эти не имеют ни фундаментальных основ, ни математически оцененной надежности.
В какой-то момент у вас спросят - а насколько релевантна действительности имитационная модель Захмана и насколько надежны выводы из нее? И у вас не будет никаких проверяемых цифр, теорем и доказательств, а лишь слова - "нет нет, все будет хорошо, зуб даю/мамой клянусь".
Я бы переименовал статью на что-то вида "Мои любимые фреймворки для повышения эффективности и качества процессов", текущее название(... любимые фреймворки для управления данными....) вводит в заблуждение.
Фреймворки для управления данными - это Airflow, DBT, Spark, Hadoop и пр и исходя из названия статьи я ожидал что речь пойдет про программные решения, а не про описание моделей зрелости процессов и методологии разработки продуктов.
Причем тут данные?
В Лин стартап видно несколько пунктов которые нужны в условиях венчура. В целом весь подход заточен на жто. Насколько это применимо вне венчура?
В целом впечатление от статьи что очень много всяких штук из книжек и очень мало практики.
Все штуки у всех так или иначе из книжек. Я всегда всем не перестаю повторять - берите любую заумную модель и пробуйте натянуть ее на себя, если взлетит - повезло, если нет - не ваше или носить не умеете )))
К чему я - нет смысла всё прикладывать к себе один к одному, нужно уметь адаптировать хорошие вещи под свои кейсы. Копните поглубже сами, прежде чем чужой столетний опыт подвергать сомнениям ))
А можете по каждому фреймворку написать по статье с пошаговым объяснением на конкретном примере/примерах? А то для человека постороннего не вполне понятно как это применимо к реальной жизни процессов.
Мои любимые фреймворки для повышения эффективности бизнеса: чем они так хороши?