что такое data driven подход
Пора внедрять data-driven. Как этот подход преобразует бизнес
Елена Герасимова, руководитель факультета « Аналитика и Data Science » в Нетологии, рассказала, на чём основывается подход data-driven, как он используется в современных компаниях и что нужно делать руководителю, чтобы успешно внедрить культуру принятия решений на основе данных.
Термин data-driven появился на стыке девяностых и двухтысячных. Именно тогда бизнес-среда стала говорить о новом подходе в маркетинге, который позволял принимать решения на основе собранных данных.
Сегодня в дефиците не только технические специалисты, способные организовать работу с данными и устройствами, но и менеджеры, понимающие, как интегрировать Data Science и новейшие технологии в бизнес-процессы, правильно нанимать специалистов, ставить им задачи и организовывать их работу.
Менеджмент data-driven — это культура принятия стратегических решений на основе данных с интеграцией аналитических отчетов в ключевые бизнес-процессы компании.
Учитывая растущее количество кросс-компетентных ролей в компаниях, появляется все больше принципиально новых позиций, которые занимаются работой с аналитикой в разном виде:
Каждая из этих позиций предполагает выступление ролевой моделью инфраструктурных изменений и трансформацию существующей в компании культуры, стратегии, видения и методики принятия решений.
При этом нередко переход к data-driven подразумевает не столько технологическую трансформацию, сколько изменение бизнес-модели компании. При таком подходе вы отбрасываете все, кроме численных данных, в целостности и актуальности которых уверены.
В каждой из новых перечисленных ролей на первый план выходят:
Роль данных в принятии решений
С руководителями мы разобрались — от данных им никуда не деться. Какую же роль играет аналитика для принятия решений?
Подход data-driven демонстрирует видение того, как компания, использующая данные для принятия решений, выглядит в реальности (совершенно необязательно иметь для этого цифровой продукт).
Помимо этого, он помогает уточнить формулировку миссии бизнеса и получить выводы, которые делают аналитику и данные ощутимыми (реальными) для людей без опыта анализа. Передовые технологии обработки данных через ИИ и машинное обучение становятся понятными более широкому кругу, когда используются для предиктивного анализа продаж, износа оборудования и риска вложений в активы.
Таким образом культура работы с данными помогает сделать очевидными практические бизнес-результаты от анализа данных и понимание текущего состояния, фокуса и намерений бизнеса.
Как стать data-driven?
Сама культура принятия решений, основанная исключительно на данных, может выглядеть простой с точки зрения внедрения, но руководителю и всей команде необходимо пройти определенные шаги и разобрать важные вопросы.
Учитывая все вышесказанное, можно сделать вывод, что переход к культуре data-driven необходим не всем.
Например, компании, основанные на сильном брендинге в качестве источника основного дохода, могут не видеть особой ценности в том, чтобы стать data-driven, поскольку решения по брендингу не требуют большого количества данных.
Отличным примером применения трансформации data-driven на уровне всей компании является Uber: обширно используются данные, которые компания получает от пассажиров и водителей.
Алгоритмы Uber рассчитывают стоимость поездки, оценивают потоки людей, меняют цены, дают рекомендации водителям, как больше заработать, основываясь на собранных данных.
В компании такого уровня вся работа с данными требовала бы найма огромного штата дата-сайентистов и их погружения в бизнес-контекст. Вместо этого компания пошла по пути построения платформы управления данными, которая позволила использовать продвинутые аналитические инструменты широкому кругу пользователей.
Но стоить помнить, что и к сотрудникам, даже высокоуровневым, в таких условиях предъявляются высокие требования. Как минимум ожидается владение базовым инструментарием аналитика:
Подводя итог, можно сказать, что руководителям, «пощупавшим» данные, гораздо проще находить со своими аналитиками общий язык в дальнейшем.
Аналитик данных — это одна из важнейших ролей в компании. Глаза, ум и здравый смысл бизнеса.
Аналитик обязан «видеть цифру за каждым человеком и человека за каждой цифрой», а также уметь продать свое видение коллегам, которые могут иметь очень разный опыт и отношение к аналитике в целом. Эта роль даже в продуктовой компании предполагает максимальное количество общения с неаналитиками.
Руководитель факультета « Аналитика и Data Science » в Нетологии
Data Driven-подход
Data Driven-подход — это способ принимать управленческие решения, основываясь на больших данных. Его используют для построения бизнес-модели или маркетинговой стратегии, при составлении плана продаж, в программировании и даже в дизайне.
Для каждой сферы выбирают конкретный тип информации, например данные о покупках, геолокации мобильных устройств, количестве поисковых запросов по теме. При поиске помещения под новую кофейню владелец может проанализировать трафик людей на улицах и выбрать место с наибольшей проходимостью.
Полное название этого подхода — Data Driven Decision Making (DDDM), то есть информационно обоснованные решения (или data driven decisions). Он стал альтернативой устаревшему подходу HiPPO (Highest Paid Person’s Opinion) — принятию решений на основе мнения руководства. Проблема этого подхода в том, что руководитель или менеджер не могут быть объективными и компетентными во всех вопросах и знать все особенности аудитории.
Melbourne Business School проводила исследование того, как компании в 46 странах используют аналитику, и выяснилось, что только 6% из них могут считаться лидерами в этом направлении. Это тот бизнес, в котором проработана аналитическая стратегия и в нее включены все подразделения, высший менеджмент принимает решения исключительно на основе данных, а также в реальном времени мониторится ситуация на рынке.
Еще 49% компаний отнесли к категории «Исследователи», так как они частично используют данные для принятия решений, но не до конца развили инфраструктуру для полноценного Data Driven. Остальные компании отнесли к «Подражателям» и «Отстающим», так как они используют данные только в одной конкретной области или не развивают аналитику вообще.
Data Driven-подход полезен на разных этапах развития:
Например, агентство RUSFAIR GROUP проводит исследования для запуска новых продуктов на рынке электронной коммерции в Китае. Они делают анализ инфополя бренда и конкурентов, затем — анализ потенциальных площадок, исследование аудитории в WeChat — самом популярном социальном приложении в Китае, Douyin — китайском аналоге TikTok и других социальных сетях. Такие исследования позволяют определить объем необходимых инвестиций и грамотно выбрать площадки для продвижения.
Фитнес-клуб в Перми через 7 месяцев после открытия поставил перед собой задачу выйти в лидеры рынка. Для доработки продающей концепции маркетологи изучили опыт конкурентов в городе, собрали данные о том, почему люди не ходят в фитнес-клубы, что их удерживает и почему бросают занятия. В результате изменений, основанных на данных, клуб увеличил выручку в два раза.
Альфа Банк в прошлом году проанализировал всю воронку продаж и поведение клиентов, которые в итоге подали заявку на карту и получили ее на руки. На основе этих данных рекламу стали таргетировать на пользователей, которые с наибольшей вероятностью заинтересуются продуктом, благодаря чему число заявок выросло в 1,6 раза.
Решения на основе данных
Для использования Data Driven-подхода требуются навыки работы с аналитикой. Во-первых, нужно уметь считывать данные из таблиц, графиков и диаграмм, потому что иначе даже на основе самых верных данных можно сделать неверные выводы. Во-вторых, нужно критически относиться к самим данным и задавать аналитику правильные вопросы:
Управление на основе данных включает в себя три подготовительных шага:
Недостатки Data Driven-подхода
Как стать Data Driven-компанией
Data Driven-организация корректно собирает, проверяет и обрабатывает данные и использует их на пользу бизнеса. Такие компании имеют отлаженный механизм работы с данными, в котором все сотрудники четко понимают задачи: data-аналитик собирает данные, отдел маркетинга умеет ставить четкое ТЗ на сбор конкретной информации, а руководство соотносит это с бизнес-целью.
Мария Михеева, продуктовый аналитик AliExpress, считает, что организация Data Driven-подхода затрагивает такие аспекты работы компании, как миссия, идеология и обучение сотрудников. Но в основе подхода все-таки лежат качественные данные — достоверные и очищенные от лишней информации, ненужной компании. На этих данных как раз выстраивается data-менеджмент. Кроме них, есть другие важные аспекты:
Главный критерий успеха в Data Driven-подходе — понимание сотрудниками компании того, зачем нужны данные. Поэтому работу над этой управленческой стратегией стоит начинать с внутреннего PR, презентации и обучения.
В каких профессиях используется Data Driven-подход
Менеджмент
Управление на основе данных — одна из причин роста компаний. Оно помогает оптимизировать расходы, повысить клиентоориентированность, отслеживать изменения на рынке и, как результат, увеличить прибыль. Пока полноценно такой подход реализуют только крупные игроки уровня Google, так как внедрение культуры Data Driven в компании — это ресурсозатратный процесс, который не всем по карману.
Маркетинг
Data Driven-маркетинг позволяет продвигать продукт на ту аудиторию, которой он интересен, что значительно сокращает рекламные расходы. Этим инструментом пользуются, например, маркетплейсы, которые собирают информацию об истории поиска своих клиентов, их покупках и интересах, чтобы предлагать им нужные категории товаров.
Веб-разработка
Разработчики опираются на данные взаимодействия пользователей и сервиса, чтобы зацепить и удержать пользователя. Например, в одной из компаний исследовали, как внутри приложения влияет на вовлечение пользователей лента, предлагающая контент на основе машинного обучения.
Кейсы компаний, которые реализуют Data Driven-подход
Управление
Управление на основе данных позволило компании «Сибур» перестроить работу отделов и избавиться от принципа «глубокого колодца», когда специалисты имеют доступ только к информации, необходимой для выполнения их обязанностей. Автоматизация отделов происходила разрозненно, большой пласт информации скрывали, мотивируя это коммерческой тайной, поэтому у менеджмента разных сегментов было недостаточно данных для анализа работы предприятия.
Внедрение Data Driven-подхода позволило открыть доступ к 80% ранее скрытой информации, сотрудники начали самостоятельно проверять гипотезы на данных, составлять интерактивные дашборды. С помощью бизнес-симуляторов компания начала моделировать различные ситуации на рынке и рассчитывать целесообразность инвестиций или запуска новых продуктов.
Разработка маркетинговых продуктов
На туристическом рынке технологию Data Driven используют, чтобы продвигать путешествия на ту аудиторию, у которой есть интерес к направлению, а также отслеживать реальную эффективность рекламы. Например, если человек интересовался турами в Испанию, смотрел билеты или отели, то он обязательно увидит таргетированную рекламу.
Анализ аудитории
Сбербанк уже несколько лет использует Data Driven для анализа поведения заемщиков. Интерактивная анкета, которую использует банк для сбора информации, позволяет выявить один из важных психологических параметров — уравновешенность или импульсивность клиента. Для банка это важно, так как рассудительные люди являются более добросовестными заемщиками, чем импульсивные. Вопросы в анкете для заемщиков помогают определить уровень финансовой грамотности, их стабильность, опыт работы и трезвое восприятие своего финансового положения.
Получите реальные знание и навыки, необходимые для работы. Обучение на основе практики и помощь в трудоустройстве. Скидка 45% по промокоду BLOG.
Нельзя просто взять и влиться в data-driven — на что обратить внимание при внедрении такого подхода
Привет, Хабр! Мы в Х5 очень любим данные и умеем с ними обращаться. Недавно мы провели «Цифровой четверг» — дискуссию с представителями ИТ-компаний, облачных провайдеров и телекомов.
На встрече обсудили data-driven подход: кейсы, «грабли» и базовые моменты, о которых стоит знать. Решили поделиться ключевыми мыслями по её итогам.
Что считать data-driven подходом
Прежде чем перейти к разговору о том, какие у компаний могут возникнуть сложности, кратко разберём, что вообще стоит понимать под data-driven подходом. В общем случае он подразумевает принятие решений с упором на аналитику, а не только интуицию и личный опыт менеджеров. Методологию используют в разработке, UX, рекламе, ритейле — в тех областях, где даже незначительные решения могут повлиять на выручку компании.
Вообще изучать, что и как покупают, ритейлеры начали ещё в XIX веке, но сам термин data-driven был популяризован в 1990-х. Мы в X5 Group используем этот подход для наполнения полок в магазинах, экспериментов, скидок и так далее. Однако он не чужд и небольшим предприятиям, когда владелец локального ресторанчика, проанализировав спрос на сезонное блюдо, решает сделать его частью регулярного меню.
В экспертном сообществе пока нет единого мнения о том, какую организацию стоит называть data-driven. Одни утверждают, что она должна использовать специализированные инструменты business intelligence (BI). Другие, что методы сбора и обработки данных не имеют значения, и для этих целей подойдёт даже Excel. Более того, если руководитель записывает данные в блокнот, ведёт расчёты на бумаге и использует их для принятия решений — это тоже data-driven подход.
Плюрализм мнений и отсутствие устоявшихся лучших практик ведёт к тому, что многие организации допускают ошибки, пытаясь стать data-driven. Далее расскажу, на какие «грабли» наступили мы в X5 Group и к чему пришли в итоге.
Почему подход может не работать
Есть мнение, что для перехода на методологию достаточно начать собирать данные — например, о продажах. Но конечно, организовать корпоративный data lake недостаточно. Необходимо следить за качеством данных на входе. Если этого не делать, в таком «озере» быстро завязнут последующие аналитические процессы. Поэтому, помимо построения моделей машинного обучения, анализа и визуализации данных, до 80% времени специалистов по данным уходит на очистку данных и их подготовку — форматирование и дедупликацию.
В этом контексте важно отметить, что не стоит ориентироваться исключительно на данные, собираемые внутри компании. Информация о конкурентах, партнёрах или франчайзи, открытая статистика аналитических агентств — всё это помогает построить более полную картину рынка и бизнеса. Если эту информацию игнорировать, есть вероятность, что принимаемые решения будут оторваны от реального мира, и data-driven подход не сработает.
Ещё методология может давать сбой из-за человеческого фактора. С данными, нейросетями и алгоритмами работают люди, и в некоторых случаях «бутылочное горлышко» образуется на их стороне. Мы в X5 Group столкнулись с этой проблемой, когда внедряли систему детекции очередей. Сама по себе задача по подсчёту людей у кассы достаточно тривиальная, и её уже много раз разбирали на Хабре. Сложности возникают, если необходимо срочно открыть новую кассу в ситуации, когда все сотрудники заняты выкладкой товара.
Похожая проблема проявилась, когда мы разрабатывали систему компьютерного зрения для определения отсутствующих на полках товаров. Во время тестовых запусков она работала отлично и уведомляла администратора, что позиция закончилась. Но внедрение технологии на масштабе не принесло ощутимых результатов. Дело в том, что на выкладку товара требуется время — сотрудники магазина не могут сделать это моментально. Кроме того, директора знают, как часто заканчивается тот или иной продукт, поэтому уведомления от интеллектуальной системы не давали значительного выигрыша по времени.
С аналогичными кейсами сталкивались и другие участники «Цифрового четверга». Кирилл Меньшов, член правления ПАО «Ростелеком», привел следующий пример:
«Мы, как и любой телеком, прогнозируем отток, чтобы работать с уходящими абонентами. Мы также прогнозируем и увольнение своих сотрудников, но здесь не имеем больших результатов. С одной стороны, здорово, что вы можете за три месяца предсказать, что сотрудник от вас уходит.
С другой стороны, его руководитель, скорее всего, уже об этом знает, и все действия, которые он мог бы предпринять, он и так предпримет. Если посмотреть A/B-тестирование с алгоритмом и без него — значимого результата нет».
— Кирилл Меньшов, член правления ПАО «Ростелеком».
У себя в компании мы строим культуру data-driven уже три года. За это время были как удачные, так и неудачные проекты, и мы отточили необходимый инструментарий. Поделюсь выводами, к которым пришли за это время.
С чего можно начать
Отталкивайтесь от кейсов. Первым делом бизнесу необходимо определить задачу, которую он планирует решить с помощью данных. Уже после этого можно переходить к выбору метрик и сбору информации. Если сделать наоборот, то компания рискует попасть в ловушку — начать «подгонять» имеющиеся данные под желаемый результат. Определившись с кейсом, также важно правильно выбрать технологическую базу. Например, не стоит решать задачу с помощью нейросетей, если есть другие, менее сложные и затратные, способы. В лучшем случае компания получит неоптимальное решение, в худшем — потеряет деньги.
В качестве примера приведу всё тот же мониторинг количества товаров. Об отсутствии продукта на полке можно судить, просто анализируя чеки. Когда условные бананы есть в наличии, их «пробивают» на кассах примерно раз в 15 минут. Если временной промежуток увеличился, то товар кончился (или что-то ещё пошло не по плану). Точность такого метода ниже, чем у видеоаналитики, однако он значительно выгоднее с точки зрения окупаемости — не нужно устанавливать дополнительные камеры в 18 тыс. магазинов.
Используйте открытые данные. Компания, которая не генерирует большие объёмы данных, тоже может быть data-driven. Достаточно использовать информацию в открытом доступе. Отчёты агентств, разного рода геоаналитика — этого хватит, чтобы начать принимать взвешенные решения о векторе развития. Эту рекомендацию поддержали участники нашей беседы:
«Если маленький бизнес хочет открыть второй магазинчик, каким образом он это делает? Или просто находит помещение, или приходит в компанию, у которой есть достаточная геоаналитика с проходимостью, покрытием, населением, и на её основе принимает решение открыть магазинчик. Для этого не нужны никакие собственные данные».
— Кирилл Меньшов, член правления ПАО «Ростелеком».
Развивайте культуру data-driven. Переход на новую методологию работы подразумевает не только технологическую трансформацию, но и изменение бизнес-модели компании. Сам переход стоит проводить постепенно, заручившись поддержкой тех, кто данные генерирует и использует. Например, на внедрение системы автозаказа в магазинах «Перекресток» [когда алгоритм самостоятельно закупает товарные позиции] у нас ушло девять месяцев. Мы разделили торговые точки на три группы. Первая сразу перешла на новый алгоритм. Директора второй группы могли править предложенные системой значения в строгих пределах. В третьей группе они имели право вносить любые корректировки. Мы постепенно переводили магазины из третьей категории во вторую, а оттуда — в первую. За это время мы выявили недостатки в работе алгоритма и поправили их, ориентируясь на решения, которые принимало руководство торговых точек.
Если говорить про X5 Group в целом, то с инструментами data-driven ежедневно работает три-четыре тысячи человек — среди них рядовые сотрудники торговой сети. Для дальнейшего развития этих инструментов важно привлекать новые кадры и обучать уже имеющихся специалистов. Хорошие базовые знания по обработке данных сегодня могут дать бесплатные профильные курсы — например, на Coursera. Однако мы разрабатываем и собственные образовательные направления — в прошлом году запустили академию по теме data science. Там сотрудники оттачивают компетенции в сфере обработки данных. Мы планируем расширить спектр программ, доступных для обучения.
Парадигмы программирования. Data Driven vs Domain Driven
Информационные технологии развиваются семимильными шагами, появляются новые устройства, платформы, операционные системы, и вместе с этим растет спектр задач, который приходится решать разработчикам. Но, не все так плохо — на помощь программистам спешат новые средства разработки, ide’шки, новые языки программирования, методологии и т.д. Один только список парадигм программирования впечатляет, а с учетом современных мультипарадигменных ЯП (например, C#) резонно встает вопрос: «Как с этим всем быть? Что выбрать?».
Попробуем немного разобраться.
Откуда взялось так много парадигм?
На самом деле ответ уже прозвучал в этом посте — разные типы задач легче и быстрее решать, используя подходящие парадигмы. Соответственно, с развитием ИТ появлялись новые виды задач (или старые становились актуальными), а решать их используя старые подходы было неудобно, что влекло за собой переосмысление и появление новых методик.
Что выбрать?
Все зависит от того, что требуется сделать. Стоит отметить, что все средства разработки отличаются, одни поддерживают одно, другие — другое. К примеру, PHP со «стандартным» набором модулей не поддерживает аспектно-ориентированное программирование. Поэтому выбор методологии довольно тесно связан с платформой разработки. Ну, и не стоит забывать, что можно комбинировать разные подходы, что приводит нас к выбору стека парадигм.
Можно пойти дальше и углубиться в эту идею: придумать качественные характеристики для данных четырех мер, добавить строгие правила и немного математики, но это, пожалуй, тема для отдельного поста. Я думаю, большинство системных архитекторов определяют данные характеристики для конкретной задачи на основе своих знаний и опыта.
После того, как вы проанализируете свою задачу по этим 4 измерениям, то, скорее всего, увидите, что определенное измерение выражено сильнее остальных. А это в свою очередь позволит определиться с парадигмой программирования, так как обычно они нацелены на какое-то одно измерение.
А, что на практике?
В нашей компании мы занимаемся разработкой бизнес приложений (стартапы, веб-сервисы, сайты, прикладные программы и т.п.) поэтому далее поговорим о парадигмах программирования, которые встречаются как в нашей практике, так и у других команд работающих в этой области.
На основе моего опыта могу сказать, что в данной сфере превалируют два подхода: ориентация на данные (Data Driven) и ориентация на логику (Domain Driven). По сути, они являются конкурирующими методологиями, но на практике могут объединяться в симбиозы, которые часто являются известными анти-паттернами.
Одним из преимуществ Data Driven в сравнении с Domain Driven является простота использования и внедрения. Поэтому Data Driven начинают использовать там, где надо применить Domain Driven (причем часто это происходит бессознательно). Проблемы же возникают с тем, что Data Driven плохо совместим с концепциями объектно-ориентированного программирования (конечно, если вы вообще используете ООП). На небольших приложениях эти проблемы почти незаметны. На средних по размеру приложениях эти проблемы уже заметны и начинают приводить к анти-паттернам, ну, а на крупных проектах проблемы становятся серьезными и требуют соответствующих мер.
В свою очередь Domain Driven выигрышен на крупных проектах, а на небольших — приводит к усложнению решения и требует больше ресурсов для разработки, что часто бывает критичным с точки зрения бизнес требований (вывести проект на рынок «asap», за небольшой бюджет).
Решив, что контекстная область у нас как на ладони, мы начинаем проектировать базу данных. Создаем соответствующие таблицы, запускаем ORM-ку, генерируем сущностные классы (ну, или в случае «умной» orm-ки прописываем схему где-то отдельно, например, в хml, и уже по ней генерируем и базу и сущностные классы). В итоге получаем на каждую сущность отдельный, независимый класс. Радуемся жизни, работать с объектами легко и просто.
Проходит время, и нам требуется добавить дополнительную логику в программу — например, находить у ордера товар с самой высокой ценой. Здесь уже могут возникнуть проблемы, если ваша orm не поддерживает внешние связи (т.е. сущностные классы ничего не знаю о контексте данных), в этом случае, придется создавать сервис, в котором будет метод — по ордеру вернуть нужный продукт. Но, наша orm хорошая, умеет работать с внешними связями, и мы просто добавляем метод в класс ордера. Снова радуемся жизни, цель достигнута, в класс добавлен метод, у нас почти настоящее ООП.
Проходит время, и нам надо добавить такой же метод и для квоты, и для инвойса и для других аналогичных сущностей. Что делать? Мы можем просто прописать во все классы этот метод, но это будет, по сути, дублирование кода и аукнется при поддержке и тестировании. Мы не хотим усложнять и просто копируем метод во все классы. Потом появляются аналогичные методы, сущностные классы начинают распухать одинаковым кодом.
Проходит время, и появляется логика, которую не описать внешними связами в бд, и поэтому разместить ее в сущностных классах нет возможности. Мы начинаем создавать сервисы, которые выполняют эти функции. В итоге получаем, что бизнес логика разбросана по сущностным классам и сервисам, понять, где искать нужный метод становится все сложнее. Решаем провести рефакторинг и вынести, к примеру, повторяющейся код в сервисы — выделяем общий функционал в интерфейс (например, делаем интерфейс — IProductable, т.е. нечто, что содержит продукты), сервисы могут работать с этими интерфейсами, за счет чего немного выигрываем в абстракции. Но кардинально это не решает проблему, получаем больше методов в сервисах и решаем для единства картины перенести все методы из сущностных классов в сервисы. Теперь мы знаем, где искать методы, но наши сущностные классы лишись всякой логики, и мы получили так называемую «Анемичную модель» (Anemic Model).
На этом этапе мы полностью ушли от концепции ООП — объекты хранят только данные, вся логика находится в отдельных классах, ни инкапсуляции, ни наследования.
Стоит отметить, что это не так плохо, как может показаться — ничего не мешает внедрять юнит тестирование, да и вообще разработку через тестирование, внедрять паттерны управления зависимостями и т.п., в общем, с этим можно жить. Проблемы возникнут, когда приложение перерастет в большое, когда сущностей станет так много, что их нереально удержать в голове, а о взаимодействии и говорить не приходится. В этом случае поддержка и развитие такого приложения станет проблемой.
Как вы наверно догадались, этот сценарий описывает использование Data Driven подхода и его проблемы.
В случае с Domain Driven мы бы поступили следующим образом. Во-первых, ни о каком проектировании бд на первом этапе речи бы не шло. Нам потребовалось бы тщательно проанализировали контекстную область задачи, смоделировать ее и перенести на язык ООП.
Например, мы можем создать модель абстрактного документа, у которого был бы набор базовых свойств. От него наследовать документ, у которого есть продукты, от него наследовать «платежный» документ, с ценой и биллинг адресом и так далее. При таком подходе добавить метод, получающий самый дорогой продукт, не составляет труда — мы просто добавим его в соответствующий базовый класс.
В итоге, контекстная область задачи будет описана используя ООП на полную катушку.
Но появляются очевидные проблемы: как сохранять данные в бд? Собственно, для этого потребуется создавать функционал для меппирования данных из наших моделей на поля в бд. Такие мепперы могут быть довольно сложными, и при изменении моделей придется изменять и мепперы.
Более того, вы не застрахованы от ошибки при моделировании, что может привести к сложному рефакторингу.