что такое принцип разумной достаточности

Цепочки поставок: принцип разумной достаточности

Объем хранимой во всем мире информации растет экспоненциально, что стимулировало развитие новых способов обработки и анализа, однако породило и новые проблемы, избежать которых, например в логистических компаниях, позволяет подход на основе принципа разум

Следуя основным принципам разумной достаточности работы с данными, можно без дорогостоящих решений выявлять закономерности в цепочках поставок, инициировать процессы по их оптимизации и управлять эффективностью.

Количественный рост объемов данных привел к качественным изменениям в способах их хранения, обработки и анализа, особенно если учесть, что 52% данных хранится сейчас в корпоративных системах, а остальные — на мобильных устройствах, в настольных компьютерах и развлекательных системах. Изменились и методы конкурентной борьбы. Компании стремятся получить доступ к информационным потокам, на исследование которых тратятся сегодня огромные средства: данные карт лояльности клиентов, данные с сайтов, обработка видео и пр. — все собираемые неструктурированные данные ложатся «на стол» алгоритмов прогнозирования и систем помощи при принятии решений. Однако сам факт повсеместной реализации подобных инициатив еще не означает их эффективности.

В бизнесе, напрямую не связанном с ИТ и телекоммуникациями, появление понятия Big Data привело к феномену своеобразного «карго-культа»: усилия по работе с большими данными имеют смысл лишь для таких корпораций, как Microsoft, Google, Facebook и Amazon, для которых соответствующие технологии являются вынужденной мерой, поскольку без них бизнес просто невозможен, а остальные компании, слепо следуя тенденциям, массово внедряют идентичные стеки технологий, фактически при этом работая со сравнительно небольшими объемами типовых данных, собираемых далеко не в реальном времени.

Каждая отрасль по-своему воспринимает понятие «большие данные». С большими пластами различных сведений традиционно работает банковский сектор, располагающий хорошо структурированными данными. Но крупнейшие представители этого сектора, образующего огромную ИТ-экосистему, уже не просто работают с большими объемами информации с целью совершенствования своих математических моделей, а пытаются решать множество дополнительных задач, позволяющих получить преимущества на рынке (реклама, обработка данных для использования в нетрадиционных для банковской сферы сервисах). Не отстают промышленность и ретейл, большинство бизнес-процессов которых связано с людьми (работа торговых точек, выкладка товаров на полки, анализ поведения потребителя), что предъявляет особые требования к способам сбора данных и обеспечения их качества. Отечественные компании ИКТ-сектора также озабочены повышением производительности обработки и качеством данных, в разных форматах поступающих по множеству каналов. Мода на большие данные не прошла и мимо сферы цепочек поставок (Supply Chain), причем здесь особо ощущается карго-культ. Объемы данных, имеющих отношение к цепочкам поставок, несравнимо меньше объемов транзакций банковского сектора или данных по потребительскому поведению в ретейле, однако уровень их нормализации достаточно высок: практически вся обрабатываемая информация находится в корпоративных системах, сотрудники следуют четкой пошаговой инструкции по работе с ними, — а это означает, что качество данных достаточно высокое.

Одна из главных технических проблем обработки больших данных, характерная не только для предприятий цепочки поставок, — децентрализация. Многие участки цепочки поставок отдаются на аутсорсинг, и, естественно, получаемая от подрядчиков информация может иметь свою собственную форму и особенности. Даже в рамках одной компании производство, транспорт и склад могут хранить и обрабатывать свои данные в разных системах: ERP, Transport Management Software (TMS), Warehouse Management System (WMS), — и для получения общего представления об эффективности цепочки поставок необходимо в одной точке сводить результаты их работы. Однако процедуры обмена информацией между этими системами настроены в основном для функционирования бизнес-процессов (документооборот, транзакционный обмен), а не для консолидации данных с целью их дальнейшего анализа. Иначе говоря, системы связаны, но информация в них существует обособленно, и, для того чтобы получать от нее максимальную отдачу, нужно отрабатывать механизмы консолидации данных.

С точки зрения бизнеса основная причина, по которой не удается использовать имеющуюся информацию для увеличения эффективности цепи поставок, состоит в низкой культуре обращения с данными, что вызвано, в частности, отсутствием ресурсов на содержание качественной ИТ-инфраструктуры. Департамент цепочек поставок прибыли не приносит, и его деятельность для бизнеса затратна, поэтому одним из основных факторов его эффективности становится не только уровень обслуживания, но и сокращение расходов на свое функционирование. Конечно, на сегодняшний день логистика уже не может функционировать без систем WMS и TMS, однако даже многие крупные компании все еще используют устаревшие версии систем «1С», SAP, PSI, которые неплохо выполняют свои прямые функции, но модули аналитики в них появились относительно недавно и эффективно работают часто лишь внутри собственной программной экосистемы. Или того хуже — аналитика настраивается только в рамках одного модуля, что опять же не позволяет добиться получения взаимосвязей между событиями. Все это на фоне того, что бизнес обычно не спешит инвестировать в обновление системы. Поэтому на сегодняшний день в логистических департаментах основным инструментом работы с данными остается выгрузка отчета в Excel. В свою очередь, департамент цепочек поставок не нанимает штат программистов и аналитиков, которые бы занимались непосредственным поддержанием нормальной работы систем ERP, TMS и WMS. Например, в департаментах логистики имеются должности бизнес-аналитиков и системных аналитиков, которые оценивают и оптимизируют физические процессы под возможности конкретной информационной системы.

С точки зрения ИТ основная работа в логистике связана с обеспечением постоянного, бесперебойного функционирования систем управления в условиях непрерывно меняющихся физических процессов, а анализ данных, прогнозирование и планирование ресурсов ведутся операционным персоналом: начальниками смен, складов, технологами и пр. При этом все отчеты обрабатываются вручную, а так как их формирование является дополнительной нагрузкой на операционный персонал, владеющий только Excel, то отчеты составляются хоть и с высокой скоростью, но без соблюдения основных принципов работы с данными, к которым относятся доступность, обогащенность и взаимосвязанность. В ходе изучения отчетности ряда логистических компаний обнаружилось, что некоторые показатели, которые должны быть вычисляемыми, не имеют ссылок на первоисточник. Например, информация о среднем грузообороте вписывается в отчетность отдельным числом, хотя должна иметь ссылку на массив данных по входу и выходу палет со склада. Иначе говоря, фактически данный показатель был высчитан вручную с помощью просмотра массива данных внутри системы. Быстро оценить, насколько корректно была обработана информация, не представляется возможным, а данные, предоставляемые таким образом, принимаются как экспертные. Это вызывает ряд проблем: вмешательство человека в обработку отчета чревато внесением ошибок; требуется больше времени для получения нужных данных; возрастает нагрузка на специалистов; уменьшается прозрачность отчетности (как правило, отчеты, составленные людьми вручную, принимаются «на веру»).

Функционирование логистики связано не только с системами управления — имеется еще множество внешних факторов, которые следует учитывать бизнесу: производительность труда, неравномерность товародвижения, погодные условия. Оценивая все многообразие таких факторов, можно предложить много гипотез (например, зависимость задержек прихода транспорта на склад от погодных условий) и, соответственно, более точно и своевременно определять колебания неравномерности грузооборота. Или, скажем, отслеживать более «приземленные» категории, такие как производительность труда каждого сотрудника, процент брака от поставщиков или боя на складе либо удельную стоимость грузообработки, в реальном времени. Учет всех факторов может сильно повлиять на эффективность логистики, однако для подтверждения тех или иных предположений требуется не только постоянно извлекать и обрабатывать данные, но и обогащать их всеми имеющимися внешними сведениями, одновременно оценивая результаты.

Сегодня на рынке представлен ряд недорогих систем бизнес-аналитики, таких как Power BI, Qliktech и Tableau, которые позволяют подключаться практически к любым источникам информации, получать нужные данные, обрабатывать их и в реальном времени выводить пользователю. Многие из этих систем сегодня ориентированы на конечного потребителя — в частности, системы Self service BI предназначены для сотрудников, не имеющих специализированных ИТ-навыков. Такие системы уже давно присутствуют на рынке и вполне могут конкурировать с инновационными решениями, которые не продаются в «коробке» и представляют собой целый стек технологий: брокеры данных (Kafka), библиотеки и языки R/Phyton, инструменты для распознавания текста, голоса и изображений. Например, компании Google, Microsoft, Facebook и «Яндекс» работают именно с такими стеками технологий, настроенных под каждую конкретную задачу, а массовый потребитель получает от них продукты типа Power BI и Google Analytics. Однако информационные гиганты имеют доступ к гигантским объемам информации, которые совсем не требуются для многих задач цепочек поставок, совершенно спокойно решаемых с помощью коробочных продуктов. Естественно, стоимость и скорость внедрения таких продуктов гораздо ниже, чем «инновационных стеков», но при этом работать с информационной системой может любой работник, а обслуживать базу данных способен штатный ИТ-специалист средней квалификации.

Конечно, данный подход не подразумевает автоматизацию процессов прогнозирования и принятия решений, однако гарантирует их наглядность, что наиболее приемлемо для цепей поставок из-за гибкости и низкого порога для внедрения и эксплуатации. При этом системы Self Service BI — лишь один из компонентов решения по максимизации эффективности использования данных.

Принципы работы с данными

Доступность — возможность быстрого получения и использования необходимых данных любым сотрудником, не имеющим навыков программирования, для проверки бизнес-гипотез. Системы Self Service BI предоставляют доступ сразу ко всему постоянно обновляемому набору данных, что позволяет их исследовать в динамике.

Обогащенность — подключение всевозможных источников внешних сведений, открывающих новые точки обзора того или иного физического явления. Каждый показатель, влияющий на изменение эффективности, не должен просто приниматься «как есть» — необходимо понимать причины, по которым этот показатель имеет то или иное значение, что зачастую зависит от многих сложно оцениваемых факторов.

Взаимосвязанность — неразрывность модели данных, требуемая для формирования единого информационного пространства, благодаря которому становится возможной работа персонала всех уровней и направлений. Следует отметить, что построение взаимосвязанной модели на нижнем уровне структуры — это идеальный фундамент для создания пирамидальной модели, в которой каждый участник цепочки поставок видит свои критерии эффективности, а также влияющие на них критерии более низкого уровня. Например, на эффективность цепочки поставок влияет эффективность транспортной и складской логистики в регионе, а на эффективность складской логистики в регионе влияет эффективность работы каждого отдельного склада, при этом директор по цепям поставок не будет спускаться до проблем конкретного склада, но, благодаря взаимосвязанности информационного пространства, начальник каждого склада может следить за своими показателями, а директор региона — своевременно выявлять проблемные склады.

Следуя основным принципам разумной достаточности работы с данными, можно, не прибегая к дорогостоящим решениям, даже в небольших объемах информации выявлять закономерности, инициировать процессы по оптимизации и следить за их влиянием на эффективность. Доступность данных позволяет сотрудникам, обладающим большим опытом и соответствующей экспертизой, оперативно генерировать гипотезы, а за счет обогащенных и взаимосвязанных данных осуществлять их проверку и оценивать влияние предлагаемых решений не только на конкретный процесс, но и на всю цепочку поставок. При этом не требуются ни машинное обучение, ни искусственные нейронные сети, ни прочие модные сегодня технологии. Такой подход доступен компаниям любого размера с любым уровнем развития ИТ-инфраструктуры и бюджетом.

Георгий Иващенко — ведущий аналитик, компания Ventra (Москва).

Источник

Оптимизация бизнес-процессов: «Правило трех ракет или принцип разумной достаточности»

«Правило трех ракет или принцип разумной достаточности»

Основная задача процессов контроля заключается в обеспечение качества основных бизнес-процессов. Учитывая тот факт, бизнес-процессы отражают информационные потоки предприятия, целью таких процессов является минимизация искажения информации при её передачи от одного объекта управления к другому. При условии, что на поиск ошибки уйдет 30 минут, три таких ошибки подряд способны парализовать информационный узел, в том случае, если и без того нагрузка на него достаточно велика.

Не смотря на очевидность вышеизложенного основная трудность возникает в другом: после того как проблема идентифицирована, порой бывает сложно донести до руководства свою точку зрения. В тяжелых случаях, в построении аргументации, мне помогает правило трех ракет.

Этот правило когда-то мне подарил мой коллега, статистик по образованию, эксперт в области менеджмента. Корнями история уходит в 60 годы. В то время бурно развивалась реактивная авиция, и как следствие активно разрабатывались средства противодействия. На заре ракетостроения вероятность того, что ракета попадет в летящую цель была достаточно не высока.

К примеру, тактико-технические характеристики зенитного ракетного комплекса «КУБ» определяют, что нормативная вероятность поражения воздушных целей для данного ЗРК составляют 70%

Итак, «Правило трех ракет»:

Допустим вероятность попадания в цель составляет 70%.
Тогда вероятность попадания в цель двух ракет составляет 91%
Вероятность попадания трех ракет составляет 97,3%
Четвертая ракета попадет в цель с вероятностью 99,2%.

Следствие: четвертая ракета повышает надежность поражения всего на 1,9%. По себестоимости четвертая ракета равна всем предыдущим, а пользы приносит не более чем на 2%.

На практике оптимизации бизнес-процессов «Правило трех ракет» позволяет ограничить количество контролирующих процессов тремя. Довольно часто приходится сталкиваться с ситуацией, когда сотрудники буквально замордованы необходимостью составления различных контрольный отчетов и сверками данных. Обычно это происходит там, где топ-менеджмент плохо понимает структуру собственного бизнеса и предпочитает перегружать сотрудников бесполезной работой. В беседах с топ-менеджментом «Правило трех ракет» помагает убедить руководство, что трех «контрольных» для большинства приложений уже достаточно.

В жизни мой коллега предпочитал при передачи денежных знаков, также придерживаться того же правила.

«При смене собственника деньги должны быть пересчитаны три раза.»

PS Благодаря замечаниям mr.Samuelson в комментариях появилась формула (5) и пример расчета (6)

«Принцип разумной достаточности», это расширение «Правила трех ракет».

Таким образом не важно количество контролирующих процессов, а важно их качество и способность оценить риски, которые несут в себе ошибки учета. Если затраты на устранение последствий ошибок несоизмеримо меньше, чем себестоимость дополнительного процесса контроля, такой процесс можно считать не эффективным.

Здесь можно пойти разными путями, либо повышать качество единственного контрольного процесса, либо решать проблему контроля системным путем.

К слову хочется заметить, что задача оптимизации бизнес-процессов, в конце концов, сводится к задаче нормализации учетных схем. К примеру в управленческом учете неплохо себя зарекомендовал принцип двойной записи разработанный ещё в 15 веке итальянским математиком Лукой Почели, но это уже другая история.

Всем, кому интресны простые и понятные определения рекомендую:

Архивы одного проекта. 1-сезон:

Источник

Почему проваливаются самые амбициозные проекты

Преподаватель GeekBrains и декан факультета веб-разработки GeekUniversity

Почему амбициозные проекты с крутыми идеями «не взлетают»? Их цели восхищают, а лидер ы вдохновляют инвесторов. Но проходит время, и они закрываются. Почему разработчики оставляют умирать множество своих сайд-проектов «в столе», так и не дав им увидеть свет? Своим мнением в этой статье делится Александр Пряхин, преподаватель GeekBrains, декан факультета веб-разработки GeekUniversity.

Часто я беру истории для статей из опыта общения с моими студентами. Не так давно, общаясь с уже окрепшими начинающими программистами на тему проектов, которые они собираются начать реализовывать, я увидел, насколько амбициозно они мыслят и строят планы. В общении с ними я обратил внимание на то, что среди студентов, не общавшихся друг с другом, красной нитью проходят одни и те же взгляды на процесс разработки и будущий продукт:

Наверняка многие из тех, кто это сейчас прочитал, узнали себя. Вполне вероятно, что кто-то даже догадался, о чем будем говорить ниже.

В информационной безопасности известен так называемый «принцип разумной достаточности». Гласит он следующее:

«Создание абсолютно надежной системы защиты информации невозможно в принципе. В любом случае остается ненулевая вероятность реализации некой угрозы или уязвимости. Любая система защиты информации может быть взломана — остается только вопрос времени и потраченных злоумышленником средств».

Именно поэтому даже большие компании не могут вкладывать бесконечно много денег в обеспечение ИБ, потому что это, по сути, бессмысленно. Согласно принципу разумной достаточности, стойкость системы будет считается достаточной в том случае, когда время ее взлома превосходит время устаревания информации или какой-либо иной разумный предел. Или же стоимость взлома системы превосходит стоимость полученной выгоды от взлома.

Но причем же тут студенты и системы защиты информации? Вообще, принцип разумной достаточности активно применялся и получил распространение еще во времена Холодной войны, когда военные аналитики производили расчеты необходимого количества боеголовок для обеспечения арсенала сдерживания. Если переводить эту тему из области безопасности в область разработки проектов, то можно сформировать следующий принцип:

«Создание идеального кода и идеального ПО невозможно. В любой программе будут оставаться ненулевые вероятности сбоев и ошибок».

Думаю, многие согласятся с этим принципом, ведь даже самые мощные и крутые дата-центры не гарантируют вам 100% безотказной работы. Теперь давайте посмотрим на тезисы, которые я привёл в самом начале и подумаем, что же в них не так и как это исправить.

Выбор технологий

Мир IT не стоит на месте. И несколько лет назад было совершенно невозможно представить то, что сегодня находится в трендах. Этому росту требований непременно нужно соответствовать. Именно к этому стремятся команды разработчиков, которые решают расширять свой стек технологий тем или иным решением. Однако это далеко не всегда бывает оправдано.

Ситуация с любой новой технологией имеет много общего с экспериментальными лекарствами. В определенной критической ситуации их применение вполне объяснимо: других вариантов зачастую не остается. Но если у вас есть выбор между существующей технологией и чем-то новомодным, но находящемся «на слуху», что выберете вы?

Правильного ответа, конечно же, нет, но пугающе часто я встречал ситуации, при которых в желании быть всегда в тренде команды разработки были вынуждены держать в стеке больше одного языка программирования на одного разработчика.

В настоящее время (на момент написания этой статьи) такой технологией является блокчейн, который сейчас хотят применить все. Не умаляя достоинств самого решения, я пока не встречал проектов (криптовалюты не в счет), где применение этой технологии имело бы смысл. Добавляя очередную технологию в стек, нужно иметь в виду, что она будет:

«Так что же, откатываемся до Assembler?». Нет. Ни в коем случае. Новые системы/языки/решения нужно внедрять, но относиться к этому следует с осторожностью. Выбирая решение для внедрения, честно ответьте себе на следующие вопросы:

Разумеется, многие могут отметить, что с таким подходом можно не запустить ни одного успешного стартапа, которые, как известно, взлетают на том, что есть. Однако в ответ на данное утверждение могу привести простой пример детской болезни любого стартапа — то, «что есть», после успешного старта часто является инфраструктурой на костылях, т.к. времени на то, чтобы привести это в порядок не было — все были сосредоточены на взлете проекта. И именно в этот момент стоит заняться тем, чтобы оставить в проекте то, что ему действительно нужно, прежде чем добавлять поверх этой кучи технологий что-то еще.

Будьте скептиком в отношении выбранного решения, как бы вам ни хотелось смотреть на него глазами убежденного оптимиста.

Оценка сил команды

Следующий риск зачастую вытекает из пятого вопроса в предыдущей части статьи. Команда амбициозных разработчиков, составляя план, может забыть о такой немаловажной части, как риски. Любой проект несет в себе подводные камни. Сегодня выяснилось, что минорная сборка одного из пакетов перестала поддерживать важную для вас библиотеку. Завтра при желании горизонтально масштабировать ваше решение вы узнаете, что выбранный механизм кэширования не скалируется. А послезавтра вы выясните, что необходимый алгоритм плохо работает с выбранным хранилищем. Примеров может быть море, но сколько бы ни повторяли все кругом тезисы о важности учета рисков, про них почему-то все равно продолжают забывать.

В идеальном варианте, когда у команды или компании есть ресурсы, нужно нанимать менеджера проектов, а еще лучше — владельца продукта (product owner). Этот человек должен будет заниматься планированием рабочего времени команды разработки совместно с тимлидом.

Согласно сложившимся практикам, на риски отводится до 30% рабочего времени команды, т.е. та оценка, которая дается разработчиками, может быть смело увеличена на эти самые тридцать процентов.

«Неслетавшаяся» команда всегда будет давать оценки с большой погрешностью. Таким образом, 30% на риски являются реальной цифрой для команды, проработавшей в устоявшемся коллективе несколько недель, а то и месяцев, выполнив не одну задачу. В самом начале коэффициент рисков можно смело увеличивать до 40%, так как будут иметь место коммуникационные издержки — не очень хорошо знакомые люди будут дольше искать общий язык.

Отдельная история — это решение, с которым команда не работала. Внедряете новый для большинства фреймворк? Умножайте сроки в три раза. Я не шучу. Если вы хотите получить на выходе что-то отличное от велосипеда с квадратными колесами, нужно будет учитывать, что люди будут учиться работать с новым решением, узнавать его, нарабатывать опыт. А это процесс далеко не быстрый.

Тем не менее, даже при самом пессимистическом взгляде на сроки выполнения задач, не стоит забывать, что IT — это зачастую не самостоятельное подразделение, а часть бизнеса, который должен функционировать и предоставлять пользователю удобный и качественный продукт. Здесь начинается вечная война между продающими департаментами и теми, кто готовит решение к продаже. Как быть, если от девяти женщин упорно требуют одного ребенка через месяц?

Наиболее реальной и удобной является практика подготовки MVC — Minimal Viable Product. Это компромиссное решение, которое заключается в поставке конечному пользователю продукта с небольшим количеством функций, но без багов и проблем в использовании.

Таким образом, с самых ранних шагов пользователь уже работает с вашим продуктом, становясь к нему лояльным, а не ожидает релиза «ну вот еще через две недельки».

Реальный пример

Дабы не быть голословным, я приведу для сравнения два описания — проект, который мои студенты хотели писать, и то, что вышло в итоге. Здесь стоит уточнить, что:

После того, как студенты прислали мне описания своих проектов, я пообщался с ними, и мы выработали совсем небольшой проект — то, что вы видите в правой части таблички.

Казалось бы, в распоряжении команды студентов, которые уже имеют достаточный опыт в программировании для того, чтобы писать самостоятельные продукты (пусть и простые), целый месяц. Почему же реальный результат настолько меньше, чем амбициозные идеи?

Как видите, есть три фундаментальных проблемы — масштаб работ, опыт команды и ответственность каждого участника. Разумеется, на них список не заканчивается, но он показывает топ проблем, которые с большой вероятностью возникнут у только что собранной команды.

Это не говорит о том, что в ней слабые программисты или плохие методики. Но хороший менеджер такой команды должен учитывать такие вещи при планировании и не давать заказчикам чрезмерно оптимистичные сроки.

Вместо заключения

То, что мы рассмотрели выше — лишь верхушка айсберга проблем командной разработки. Я осветил некоторые наиболее яркие по моим наблюдениям. Как видите, решения, применяемые для устранения проблем, довольно простые. Нужно лишь не забывать следовать несложным истинам

Источник