Модели не для моделей
Пол Кругман, лауреат Нобелевской премии по экономике 2008,
«предпочитая анализировать реальность» склонен придерживаться тезиса о том, что
модели должны быть максимально простыми
и должны строиться не сами для себя, а для решения конкретных экономических
задач. Мой богатый практический опыт построения бизнес-моделей для целей
автоматизации процессов управления арендными отношениями на различных
предприятиях, позволяет мне считать, что приведенный тезис в той же мере
применим и для аналитических задач в IT-сфере.
«От лидеров этой (Массачусетского технологического института (MTI) - ред.) школы Роберта Солоу и Пола Самуэльсона <…> Кругман перенял вкус к простым прозрачным моделям, соединявшим реальные данные с необходимым минимумом математики и позволявшим ухватить суть изучаемого вопроса, отбрасывая все второстепенное. Здесь шаг за шагом формируется фирменный стиль ученого - радикальное упрощение как стратегия моделирования. Разительный, кстати, контраст с современным экономическим мейнстримом, в котором изощренной математики, как правило, на порядок больше, чем собственно анализа процессов и явлений реальной хозяйственной жизни.» С полным текстом статьи можно ознакомиться в журнале «Эксперт» №41.
Применение стратегии радикального упрощения при построении бизнес-моделей позволяет получить следующие выгоды:
- Модель становится наглядной и содержит минимальное количество элементов, доступных для восприятия (известно, что человек может воспринимать не более 6-7 объектов одновременно);
- На создание эскизной модели уходит существенно меньшее количество времени, чем на создание относительно полной и достаточно глубоко проработанной модели;
- Небольшое количество объектов, используемых при построении простых моделей, легко контролировать и легко изменять.
Ограничения применения стратегии радикального упрощения:
- Модели с небольшим количеством факторов могут быть опасны, если приходится иметь дело с большими и сложными информационными системами, применяемыми в областях с высокой степенью риска, например, авиация, банковские системы и др.
- Не стоит ограничиваться построением эскизных моделей на этапе проектирования информационной системы. Все сущности и их атрибуты, все взаимосвязи между сущностями, все сценарии использования системы пользователем, а зачастую и интерфейсные решения, должны быть продуманы и проработаны до мелочей, прежде чем быть отданными в разработку.
Где-то мне встречалось одно хорошее правило: если ваша модель слишком сложна и содержит слишком большое количество разнообразных факторов, отложите её и вернитесь к ней спустя несколько дней - возможно, вы сочтете некоторые из них несущественными или вовсе избыточными, и ваша модель значительно упростится.
Всё гениальное просто…
«От лидеров этой (Массачусетского технологического института (MTI) - ред.) школы Роберта Солоу и Пола Самуэльсона <…> Кругман перенял вкус к простым прозрачным моделям, соединявшим реальные данные с необходимым минимумом математики и позволявшим ухватить суть изучаемого вопроса, отбрасывая все второстепенное. Здесь шаг за шагом формируется фирменный стиль ученого - радикальное упрощение как стратегия моделирования. Разительный, кстати, контраст с современным экономическим мейнстримом, в котором изощренной математики, как правило, на порядок больше, чем собственно анализа процессов и явлений реальной хозяйственной жизни.» С полным текстом статьи можно ознакомиться в журнале «Эксперт» №41.
Применение стратегии радикального упрощения при построении бизнес-моделей позволяет получить следующие выгоды:
- Модель становится наглядной и содержит минимальное количество элементов, доступных для восприятия (известно, что человек может воспринимать не более 6-7 объектов одновременно);
- На создание эскизной модели уходит существенно меньшее количество времени, чем на создание относительно полной и достаточно глубоко проработанной модели;
- Небольшое количество объектов, используемых при построении простых моделей, легко контролировать и легко изменять.
Ограничения применения стратегии радикального упрощения:
- Модели с небольшим количеством факторов могут быть опасны, если приходится иметь дело с большими и сложными информационными системами, применяемыми в областях с высокой степенью риска, например, авиация, банковские системы и др.
- Не стоит ограничиваться построением эскизных моделей на этапе проектирования информационной системы. Все сущности и их атрибуты, все взаимосвязи между сущностями, все сценарии использования системы пользователем, а зачастую и интерфейсные решения, должны быть продуманы и проработаны до мелочей, прежде чем быть отданными в разработку.
Где-то мне встречалось одно хорошее правило: если ваша модель слишком сложна и содержит слишком большое количество разнообразных факторов, отложите её и вернитесь к ней спустя несколько дней - возможно, вы сочтете некоторые из них несущественными или вовсе избыточными, и ваша модель значительно упростится.
Всё гениальное просто…