Бизнес-образование по-европейски в Праге
От краткосрочных бизнес-семинаров, мастер-классов, стажировок и тренингов до многомесячных бизнес-курсов
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Несколько тезисов для умных друзей о построении моделей
Обсуждения-аналоги
-
+82 / 2011-06-13 16:27:28,
[не прочитана] -
+4 / 2013-10-26 23:57:51,
[не прочитана] -
+15 / 2013-08-14 19:18:19,
[не прочитана] -
+10 / 2013-08-13 16:43:53,
[не прочитана] -
+7 / 2011-07-01 18:56:59,
[не прочитана] -
+16 / 2011-06-10 19:12:51,
[не прочитана] -
+2 / 2024-01-05 14:51:18,
[не прочитана] -
+1 / 2011-05-22 11:25:21,
[не прочитана] -
+6 / 2016-04-26 13:52:44,
[не прочитана] -
+1 / 2011-06-16 11:24:38,
[не прочитана] -
+1 / 2011-07-26 14:57:36,
[не прочитана] -
+1 / 2012-08-27 10:39:44,
[не прочитана] -
+7 / 2015-04-07 19:12:19,
[не прочитана] -
+1 / 2013-06-29 16:04:35,
[не прочитана] -
+1 / 2014-01-01 11:28:40,
[не прочитана] -
+13 / 2015-01-27 08:19:20,
[не прочитана] -
+10 / 2011-06-10 19:00:37,
[не прочитана] -
+8 / 2015-02-12 16:42:40,
[не прочитана] -
+4 / 2011-07-27 19:08:01,
[не прочитана] -
+1 / 2013-10-02 11:40:48,
[не прочитана] -
+2 / 2013-10-24 19:56:32,
[не прочитана] -
+1 / 2013-10-26 11:58:20,
[не прочитана] -
+3 / 2014-06-02 19:23:49,
[не прочитана] -
+1 / 2014-06-02 17:58:28,
[не прочитана] -
+1 / 2014-12-22 18:31:55,
[не прочитана] -
+15 / 2016-04-08 04:50:36,
[не прочитана] -
+1 / 2015-01-26 09:29:55,
[не прочитана] -
+32 / 2016-08-12 10:49:59,
[не прочитана] -
+4 / 2015-05-17 14:16:25,
[не прочитана] -
+4 / 2015-05-11 12:37:10,
[не прочитана] -
+1 / 2016-04-25 19:20:41,
[не прочитана] -
+1 / 2016-04-26 16:07:36,
[не прочитана] -
+1 / 2016-04-26 16:55:51,
[не прочитана] -
+20 / 2023-04-07 17:12:08,
[не прочитана] -
+15 / 2018-01-27 17:26:44,
[не прочитана] -
+4 / 2018-07-26 10:28:07,
[не прочитана] -
+1 / 2018-07-28 10:54:35,
[не прочитана] -
+1 / 2020-07-01 11:44:28,
[не прочитана]
2013-07-28 19:38:53
О построении моделей
- Классификация НЕ обязана корректно описывать часть окружающего мира, она просто "заточена" под конкретный функционал.
- Большую непротиворечивую классификацию невозможно создать по теореме Геделя о неполноте.
- Если СЕЙЧАС классификация непротиворечива, то это только потому, что проект ещё мал и данные (в т.ч., типы данных) еще не все учтены.
- Классификация должна быть НЕ “правильная”, а компактная (маленькая) и не растущая СТРУКТУРНО при увеличении потока требований.
- При хорошей модели по мере роста проекта добавляются записи в справочники, но не "ветки" в структуру.
- При добавлении новых требований к объектным структурам, увеличивается число веток. Поэтому они плохи.
- При добавлении новых требований к функциональным структурам, увеличивается число записей в справочнике.
- Поэтому функциональные структуры легче продвинуть к идеалу. Их также легче сопровождать.
- Надо не только учиться “обрабатывать сложные деревья” (модная ВУЗовская тема), но и проектировать модель так, чтобы функциональность росла, а "ветки" нет. В идеале, вообще обходиться без задачи обработки сложного дерева.
- В алгоритмах обработки деревьев нет ничего плохого, но люди несовершенны. Очень многие из них “ветвят проект” только потому, что их учили “обрабатывать деревья”. А задача сделать функциональную, но одновременно компактную модель не ставили вовсе.
Всякую модель полезно проверять на "максимум потока", и, при этом, задавать себе такие вопросы:
- Когда поток вырастет в 1000 раз, то какая подсистема не выдержит в первую очередь?
- Нельзя ли вовсе обойтись без этой подсистемы? Как перестроить проект так, чтобы этой подсистемы не было, а функциональность сохранилась?
- Если удалось перестроить проект так, что удалось обойтись БЕЗ подсистемы по предыдущему пункту (а функциональность сохранить), снова применить прием увеличения максимума потока и снова спросить себя:
- Когда поток вырастет ещё в 1000 раз, то какая следующая подсистема испортится прежде остальных?
- Как обойтись без неё? (далее цикл)
- Если соответствующую подсистему (см.выше) полностью устранить не удалось, но удалось её реализовать иначе (лучше и проще), то попробовать экстраполировать СТРУКТУРУ перестроенной подсистемы на весь проект. Хоть это и нелогично.
Пояснение: из работы "Идеализация технических систем" [Ю.Саламатов, И.Кондраков] известно, что подсистема, испытывающая максимальные претензии, после ее улучшения “поглощает” соседей (т.е., способна выполнить функции ближайших подсистем) и становится эталоном для системы в целом.
Прошу прощения у всех, кому это не интересно, а Вы случайно прочли :)
Спасибо,
2013-08-10 14:54:11
Уважаемые Коллеги!
Для удобства разные обсуждения одной темы размещены слева на панели:
 |
 |
Обсуждение 1 темы о построении моделей (медицинский центр) |
|
|
Обсуждение 2 темы о построении моделей (продажа запорной арматуры) |
Спасибо,
2013-10-24 19:47:46
Уважаемый Сергей Валерьевич!
В связи с Вашими тезисами возникло несколько вопросов:
1. Предположим мы решили собрать картотеку типовых бизнес-проблем и свести их в некий общий каталог. Вероятно, исходно такой каталог состоял бы из двух больших разделов: маркетинга и менеджмента, но как в целом следовало бы все это классифицировать?
- по типу проблем, например: "проблемы продаж"?
- по причине/источнику проблем: например, проблемы, связанные с неверной моделью з/п?
- как-то иначе?
Т.е. в каком случае систему можно было бы назвать функциональной, а не объектной? Возможно, Вы такую систему уже и сделали, нам просто хотелось бы понять принцип классификации.
2. Верно ли, что в итоге такие проблемы разложились бы по этапам S-кривой, или мы здесь заблуждаемся?
С уважением,
2013-10-26 23:57:51
Уважаемый Стас!
собрать картотеку типовых бизнес-проблем и свести их в некий общий каталог (...)
- по типу проблем, например: "проблемы продаж"?
- по причине/источнику проблем: например, проблемы, связанные с неверной моделью з/п?
- ........................
Существует бесконечное множество вариантов продолжения данного списка. Но приведённый Вами пример носит, всё же, умозрительный характер, а при конкретном исследовании имеются более узкие формулировки и более частные задачи. Так что, перебирать многочисленные варианты для классификации не приходится.
Обычно изначально есть определённый массив решённых задач - их накапливаешь и подбираешь аналоги. Когда общее число записей становится большим, то организация картотеки заключается в том, чтобы упрощать извлечение аналогов и их групповую обработку после извлечения, а не в том, чтобы делать "правильной" картину мира. Это и будет функциональным подходом. Группирую так, чтобы затем извлечь максимум аналогов простейшим и удобным способом.
Вероятно, исходно такой каталог состоял бы из двух больших разделов: маркетинга и менеджмента
А это - как раз - объектный подход ("правильно" разложить существительные по полкам). Будет громоздко, неудобно и путано. Причём вместо слов "маркетинг" или "менеджмент" могут стоять любые иные существительные, например, "слоны" и "мамонты" или "вилки", "ложки" и "тарелки" и проч. - проблема порождается не темой, а способом организации данных и определённым ошибочным желанием ("хочу максимально полно и непротиворечиво описать действительность").
2. Верно ли, что в итоге такие проблемы разложились бы по этапам S-кривой, или мы здесь заблуждаемся?
Какие именно проблемы и с какой радости?
Спасибо,