Результаты исследования: мнение компаний и покупателей о новых технологиях разительно различаются

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

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

Исследование, о котором идет речь, проведено IBM Institute for Business Value (IBV). Сотрудники этого подразделения IBM опросили около 600 руководителей высшего звена различных компаний и более 6000 потребителей самых разных цифровых товаров.

Результаты опроса очень интересны. Так, согласно данному исследованию (англ. «The Experience Revolution: Digital Disappointment—Why Some Consumers Aren’t Fans»), потребители чаще всего недовольны новыми придумками производителей по следующим причинам (ранжируется в порядке важности):
• Продукт/сервис не работает так, как ожидалось;
• Неудобно;
• Пользоваться можно, но сложно;
• Слишком запутано.

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

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

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

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

Авторы исследования рекомендуют компаниям следующее:
• Создавать продукты и услуги, основываясь на ожиданиях потребителей, а не собственном мнении;
• Тщательно анализировать потребности покупателей, их желания и мнения, основываясь на разных факторах, а не только на простейших критериях вроде возраста;
• Поставить простоту и практичность продукта во главу угла. Инновационность, как показывает практика, не делает клиента счастливым сама по себе;
• Разрабатывать маркетинговую стратегию, основываясь на данных полученных в результате анализа, описанного выше. В первую очередь, потребителям нужно показывать, чем продукт важен/привлекателен для самого пользователя, а не сам по себе.
ссылка на оригинал статьи https://geektimes.ru/post/288566/

Хочу все знать: Бизнес-Анализ, ч.1

С чего все началось.

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

Читающий песик

Итак, целью статьи является показать, чего ожидают и в чем нуждаются пользователи результатов работ бизнес-аналитиков. По сути, статья писалась не только для бизнес-аналитиков, но и для тех, кто вынужден пользоваться результатами их труда. И чтобы не просто «читать и материться», а иметь возможность объяснить, чего же они пропустили или не учли в своей работе

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

Бизнес-Анализ? Нет, не слышал

Например, некто Howard Podeswa, в своей книге «UML for the IT Business Analyst » дает такие определения (второе издание, раздел 1, страница 1):

Существуют два вида бизнес аналитиков:
— Обычный (не IT) бизнес-аналитик – тот, кто работает в контексте бизнеса в целом. Такой специалист участвует в совершенствовании процессов, оптимизации издержек и т.д.
— Бизнес-аналитик в IT: тот, чья работа происходит в рамках отдельных IT проектов – закупки, внедрения, внесение изменений и т.д. Его задачей является взаимодействие с заинтересованными лицами со стороны заказчика (бизнес пользователи, технический персонал и т.д.) для сбора требований, исходящих от бизнеса

«International Institute of Business Analysis» (www.iiba.org) в «BABOK Guide 2.0», определяет (раздел 1.2, стр. 3):

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

Object Management Group (www.omg.org) в спецификации «BPMN 2.0» дает такое определение (стр. 499):

Бизнес-Аналитик, это специалист, который анализирует потребности и проблемы бизнеса, консультируется с пользователями и заинтересованными лицами, для нахождения возможностей улучшить отдачу от бизнеса с помощью IT, а также задает, управляет и отслеживает указанные требования в бизнес-процессах

Традиционно для запада, единого определения нет, но, тем не менее, есть некие общие черты:
маяк бизнес-анализа

  • сбор и документирование требований, пожеланий и целей, к которым стремится заказчик;
  • анализ и документирование процессов;
  • анализ собранной и систематизированной информации и выработка рекомендаций по процессам и/или их отдельным этапам (тут уже можно говорить про автоматизацию и прочие «плюшки»).

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

Сбор и документирование требований, пожеланий, целей бизнеса

Итак, как говориться, пора разобраться, ради чего все это затевалось. Все это, в смысле «бизнес». И если сами руководители и/или работники этого не знают, «тогда мы идем к вам» (ц). На самом деле, это очень важный этап и тут есть свои, совсем неочевидные сложности.

Традиционно, начнем с определений. Что есть бизнес?
Бизнес, говоря по-русски, это просто некая деятельность или занятие, на которые мы тратим свои ресурсы (время, деньги) и свои способности. И любой «бизнес» существует не сам по себе в вакууме, он служит «удовлетворению потребностей». Все это наверняка уже слышали не раз. Так вот, выявление этих самых потребностей и является одной из задач бизнес-аналитика на первом этапе исследования.

Легенда

Когда-то давно вычитал, что девизом IBM в стародавние времена было утверждение:
«мы продаем нашим заказчикам не то, что они хотят, а то, что им нужно».
Уж не знаю насколько это правда, но постановка вопрос весьма показательна.

И чтобы нам было все это славословие более понятным, давайте отвлечемся от гранита науки, к более податливым материям – к примерам. Представим, что перед нами стоит задача исследовать бизнес «Почты России». Этот пример, думаю, будет многим близок, поскольку с почтой каждый из нас сталкивался. Итак, что же является целью данной организации? Какую потребность она (организация) удовлетворяет? Многие сходу ответят что это – «доставка почтовых отправлений». И это будет не совсем верным ответом. Спросим несколько иначе, а что отражает потребность заказчиков в «отправке писем, посылок и так далее»? И тут уже наверняка все догадались – передача информации и ценностей на расстояния. Именно это и является той бизнес-потребностью, которую данная организация должна удовлетворять.

Чувствую, что будут недовольные ухмылки, мол «крутишь, вертишь, надурить хочешь» автор. Ан нет. Еще раз взглянем внимательно. Человек не родился со знанием, что для того, чтобы чего-то сообщить другому человеку за лесами и полями (в смысле который находится очень далеко) надо сначала все это записать на бумагу, запаковать в конверт и отправить с помощью почты. Таковыми были требования вследствии неразвитости средств связи.

И мы видим, что неверное определение целей бизнеса приводит к его (бизнеса, предприятия) умиранию. Ведь сотовая связь, факс, электронная почта – эти средства тоже удовлетворяют туже самую потребность – передача информации на расстояния. То, что руководство «Почты России» этого не поняло, это бывает, а вот то, что бизнес-аналитики, которых они наверняка звали, этого не указали – вот это уже проблема. Если говорить о почте, то ее задачей была и остается «передача информации и ценностей на расстояния». Не отправка посылок, конвертов, бандеролей – а именно «передача информации и ценностей», безотносительно способов, как она это делает, даже пусть телепортирует, или же производит на месте.

С появлением сотовых телефонов, было очевидно, что писать письма станут меньше. Остаются только те, кому важна передача информации на физических носителях. Вот что мешало поставить факсы и получить права нотариусов в каждом отделении почты, чтобы человек на другом конце получал заверенную копию? В дальнейшем, можно было использовать сканирование и передачу файла для печати в нужном отделении (благо цифровые подписи уже в ходу). Опять же, денежные переводы по России с получением/отправлением в каждом отделении. А если вспомнить про переговорные пункты, которые часто были на почтах, что мешало организовать VoIP, или ее аналог для дешевых звонков? Помешало именно непонимание целей организации. Теперь же все сладкие куски достались курьерским службам, системам денежных переводов и прочим VoIP операторам. А надо то было, всего лишь чуточку подумать.

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

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

Очевидно, что бизнес-аналитик должен понять и зафиксировать все требования и задачи, которые будут озвучены, именно с точки зрения бизнеса – удовлетворение вполне конкретных потребностей. При этом, при их описании, желательно избегать всевозможных туманных определений задач в стиле «сделать счастливой тетю Глашу», или же постараться максимально их конкретизировать (например, «для должности «помощник»– уменьшить объем выполняемых работ до 5ти операций, общим временем не более 6 часов в день»). Ну и самое главное, все задаваемые требования должны иметь численное, абсолютное значение. Допустим, мы получили требование: «уменьшить затраты на доставку отправлений в рамках одной области на 5%». Уменьшить что? Затраты чего: труда сотрудников, времени доставки, стоимости доставки или все вместе в некой пропорции? Как все это считать? В идеале, хотелось бы, чтобы требования фиксировались в виде, близком к следующим примерам:

затраты времени на доставку отправлений массой до 1 кг, в пределах 300 км от места отправления, с момента оформления отправления в офисе, до момента готовности к его выдаче в отделении получателю, необходимо уменьшишь с 24 до 16 рабочих часов

себестоимость доставки отправлений в пределах 300 км от места отправления, массой до 1 кг, с учетом:

  • затрат на оформление отправления;
  • зарплат всех занятых в процессе приемки, обработки, доставки, выдачи и иных необходимых процедур (включая уборку помещения, обслуживание транспорта и помещений, выписку документов и т.д.);
  • амортизации оборудования;
  • стоимости расходных материалов;
  • неизменного уровня качества и скорости доставки.

должна быть снижена с 50 до 45 руб., в пересчете на одно отправление, при общем количестве отправлений не менее 50 в день

Наверняка тут же возразят, «a как быть с требованиями в стиле «увеличить прозрачность процессов?» На самом деле, тут нет ничего сложного. Для начала, необходимо понять, какие причины побудили заказчика указать подобное требование? В данном случае, это является следствием того, что невозможно проконтролировать движения материалов/товаров/отправлений в процессе работ или иных действий. Поэтому, подобные требования можно записать в стиле:

время предоставления информации на запрос о нахождении произвольной партии/единицы товара, не должно превышать 5 минут с момента его отправки/формирования

или же

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

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

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

Едем дальше. Когда мы говорим о задачах, которые ставит заказчик, бизнес-аналитик должен убедиться, что есть реальные возможности эти задачи выполнить. Вот, допустим, ставится задача гарантировать максимальный срок доставки посылок из Калининграда в Петропавловск-Камчатский в 3 дня. Супер. Все будут только счастливы. Однако, анализируя транспортные возможности, мы видим, что чисто физически, иногда в славном городе вулканов и «Авачи» неделю может «не быть погоды». То есть неделю самолеты туда не летают. И в таком случае, все обещания, улучшения процессов и чего угодно еще, не позволят решить данную задачу в текущих условиях. Поэтому такие задача следует или отвергать на самых ранних стадиях, или же обставлять условиями, когда они могут быть достигнуты.

Случай из практики

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

Как мы видим, требование в принципе простое. При поверхностном анализе – все прекрасно:

  • действительно, в контракте (договоре) с каждым клиентом присутствует приложение с указанием набора номенклатуры, наличие которого (набора номенклатуры) обеспечивает применение скидки на весь заказ;
  • более того, в 1С (с которой мы будем интегрироваться) в накладной такое поле тоже присутствует, и он часто заполнено в рабочих накладных;
  • все сотрудники филиала, от Директора филиала, до менеджера проекта со стороны заказчика и рядовых сотрудников утверждают, что все именно так и работает, причем автоматически.

Но, поскольку мне надо было подготовить не просто «некий документ» а полный и непротиворечивый источник информации о проекте и процессах, я должен был указать не только требования, но и то, как они (требования) должны и могут быть реализованы. Этот ньюанс зачастую упускают, но он очень важен.

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

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

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

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

Надеюсь, все прониклись и осознали, что для каждого требования и задачи, необходимо убедится в возможности ее реализовать и приводить разъяснения с примерами и подробными пояснениями (с ограничениями, условиями и деталями по источникам, средствам, форматам данных, условиями их применимости и прочим). Забегая вперед, тоже самое относится и к найденным недостаткам, проблемам, нестандартным ситуациям. Крайне желательно также приводить причины их появления.

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

  • товары вводились одновременно несколькими операторами по новым поступлениям из накладных, в результате каждая приходная накладная использует свой вариант товарной позиции;
  • новые товарные позиции вводятся одним ответственным лицом, но таким образом «эмулируется» отсутствующий или отключенный «партионный учет» в учетной системе;
  • «двойники» являются результатом объединения нескольких баз и многие из них (позиций-двойников) отсутствуют в остатках и применяются только для корректного отображение исторических документов/проводок, не влияя на текущую работу.

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

И в завершении этого раздела, заострю внимание, что бизнес-процессы не имеют никакого отношения к таким экономическим показателям, как объемы и цены продаж. Это зона ответственности коммерческого отдела вообще, и маркетинга – в частности. Иными словами, маркетинг отвечает за формирование спроса, а работники и бизнес-процессы – за его удовлетворение. И единственное, как бизнес-процессы любого предприятия могут повлиять на прибыль – только снижением издержек включая затраты времени. Ценообразование, формирование требований к продукции, объемы производства/реализации – все это касается маркетинга и только маркетинга.

Быль

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

  • отдел продаж ни в коем случае не должен иметь задачи отгрузить как можно больше продукции, его задача — обеспечить, чтобы продукт был представлен на рынке и был доступен покупателю везде;
  • если продукт присутствует в продаже и легкодоступен покупателю, но его мало покупают, то это не проблема отдела продаж – это проблема отдела маркетинга.

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

продолжение тут

Источники изображений:
1. Изображение маяка взято тут.
2. Песик отсюда
ссылка на оригинал статьи https://habrahabr.ru/post/327354/

Хочу все знать: Бизнес-Анализ, ч.2

первая часть тут

Анализ и описание процессов

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

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

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

Итак, у нас есть цель – доставка ценностей от заказчика – получателю. У нас есть вариант достижения этой цели:

  • заказчик приходит, сдает свои упакованные ценности (а упаковка — это уже отдельный процесс и бизнес, который мы игнорируем сейчас);
  • компания обеспечивают доставку бандероли (упакованных ценностей) туда, где их может получить получатель;
  • получатель, приходя в заранее согласованное место, получает отправление.

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

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

  1. Получатель не получил бандероль
    • Получатель утверждает/уверен, что именно данная, конкретная бандероль им не получена (Как мы может это проверить? Кто и как ее передает, и как это фиксирует?).
    • Бандероль не доставлена, когда ожидалась:
      • Нет согласованных требований к срокам доставки (Почему были другие ожидания? Фиксировалось ли это каким либо образом?).
      • Компания (или отдельные ее сотрудники, подрядчики) не имеют возможности выполнить работу: болеют, нет соответствующей квалификации, недоступны тех. средства (Кто за этим следит, и когда об этом стало известно?)
      • Компания (или отдельные ее сотрудники, подрядчики) ничего не знают о данной бандероли. (Как это проверить?)
  2. Получатель не доволен тем, что и как получил. Например, вложение было повреждено. (В данном случае не понятно, проверялись ли вложения, или откуда эти «требования к бережному обращению» могли быть известны исполнителю/работнику. Более того, как исполнитель/работник может быть уверен, что требования, предъявляемые к вложению и/или обращению с отправлением, соответствует ожиданиям конкретного заказчика?)
  3. Отправитель отказался от услуг:
    • заказчик не смог воспользоваться услугой, например, была очередь, или он не получил информации, что услуга доступна – например сотрудник не смог ее разъяснить, или же у него недостаточно квалификации чтобы ее оказать (Фиксируются ли обращения и результаты?).
    • предложенная услуга не соответствует пожеланиям заказчика, например по цене, или иным условиям (Как об этом мы можем узнать?).

Это похоже на «управление рисками», и нам необходимо отразить эти риски и поспособствовать их минимизации. Как видим, даже не вникая глубоко в фактические детали, мы уже получили общее представление о том, что должно делаться и что нам нужно контролировать. Безусловно, этого недостаточно чтобы получить полную картину происходящего или давать какие-либо советы. Тем не менее, на данном этапе этой информации достаточно, поскольку она уже раскрывает особенности, которые при описании «As Is» могут быть упущены. И ценность этой информации высока, поскольку любой, кто будет иметь наглядное представление о том, что делается, как и для чего – всегда сможет оценить, насколько текущие реализации процессов адекватны целям и условиям.

Итак, мы уже знаем о нашем процессе кое-что, но как все это сделать доступным и понятным для любого человека, без прочтения «… дцати» страниц текста? Ответ известен всем – надо просто нарисовать. И, как обычно, нас поджидает другой «сюрприз». Большинство используемых методологий графического отображения бизнес-процессов рекомендуют на диаграммах отображать именно технические детали (BPMN, UML, EPC и др.). В этом нет ничего плохого и на этапе анализа и подготовки рекомендаций диаграммы «As Is» и «To Be» именно такими и должны быть. Но когда мы описываем непосредственно сам процесс, его логику и правила, эти детали, как песок пустыни, покрывают любые сокровища. В результате, мало кто в состоянии сразу оценить корректность или ошибочность самих процессов или их понимание бизнес-аналитиком.

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

Мой вариант такой диаграммы я называю «Сафед-диаграмма», от таджикского/персидского «сафед»- ясный, чистый, белый. По сути, Сафед-диаграммы содержат консолидированную и обобщенную информацию о логике процессе, что упрощает понимание. Сами диаграммы я «рисовал» в Excel, так что никаких магических инструментов так же не требуется. И еще небольшое пояснение, я не привожу ни текстового описания процесса, но то, почему указаны те или иные особенности и детали, ни даже пояснений к используемой нотации. На данном этапе моя цель – показать, насколько диаграмма-схема может быть понятной даже без прочтения текстового описания и без приведения расшифровки к используемой нотации.

Итак, отображение логики процесса «указания услуги доставки бандероли» будет выглядеть примерно как на рисунках ниже (я разбил сам процесс на 3 части, чтобы было удобно его рассматривать):

Часть 1 (крупнее):
первая часть схемы процесса

Часть 2 (крупнее):
вторая часть схемы процесса

Часть 3 (крупнее):
последняя часть схемы процесса

И дополнительные схемы — движение и источники данных для процесса (крупнее):
источники и хранилища данных

Как можете видеть, на диаграммах явно указано, кто и что делает, откуда берет или где фиксирует данные, кто отвечает за их (данных) актуальность и заполнение. Хоть сейчас составляй должностные инструкции. Более того, видно, какие должностные обязанности можно совместись. Одним словом, мы прозрели и явно видим, что должно происходить.

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

  1. Если мы рассмотрим этап транспортироки, то видим, что мы никак не контролируем, что происходит с бандеролью после перадачи ее в транспортный отдел или компанию. Таким образом, надо или дополнительно требовать со смежников ведение мониторинга доставки, или же на нашей стороне контролировать «журнал транспортировки», на случай задержек или «пропаданий» отправлений. По-хорошему, этот нюанс должен быть отдельно описан и отражен на схеме процесса.
  2. Для роли/должности «Комплектовщик» не указаны источники регламентирующих данных. С одной стороны, вся информация может быть в «наряде на доставку» и/или в «Журнале транспортировки», с другой же – это может быть результатом упущения бизнес-аналитика. В любом случае должны быть пояснения, поскольку появляется риск неверных действий сотрудника со всеми вытекающими.
  3. Аналогично, как и в предыдущем замечании, при получении отправлений из транспортировки и далее, на финальных стадиях, ни для одного их сотрудников не указаны регламентирующие источники

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

Случай из практики

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

Представители компании каждый раз с гордостью заявляли, что в компании все процессы не только описаны, но и промоделированы в ARIS. Это не считая «полного Kaizen» во всем. При этом, к сожалению, предоставить описание процессов так и не смогли, в рузультате в спешке провели экспресс «бизнес-анализ», качество которого было ужасным.

И вот, уже на этапе внедрения системы, со всевозможными подписанными высокими сторонами планами, схемами, описаниями, готовлю команду заказчика, которая будет внедрять, поддерживать, эксплуатировать систему на головном предприятии и у дистрибьюторов. И снова чудеса случаются с «рекомендованным ассортиментом». На этот раз, из примерно 20 позиций (единых для всех), около половины отсутствуют в рабочей информационной системе. То есть, в Axapta у заказчика нет товарных позиций, которые пару месяцев назад, подписаны Генеральным Директором, как ключевые, для продаж в течение года.

Начинаем разбираться, Менеджер Проектов (ПМ) со стороны Заказчика, Генеральный, начальник Коммерческого отдела – не могут внятно сказать, откуда вообще этот список был взят. Как понимаете, в описанных бизнес-процессах, ни сам приказ, ни то, как он формируется, даже не упомянуты. На выписе, в бухгалтерии (там сидят на 1С) — этих позиций нет. На следующий день, первую половину дня все участники представления находят поводы на проблему «забить» (планерка, совещание, встреча, митинг, звонок, обед). Своими силами нашли некоторые позиции, отдаленно напоминающие те, что в приказе. Все равно порядка 5ти из них – не имеют даже отдаленных аналогов. После обеда, ставлю всех на уши, перерыли все, что только могли – нет товара такого и точка. Ни IT, ни выписка, ни бухгалтерия не сдаются, и молчат как партизаны на допросе в гестапо. И тут, после повторенного множества раз вопроса «а как эти данные в итоге появляются в системе, и кто за это отвечает» одна из девушек неуверенно предлагает, «а почему бы вам не спросить в отделе НСИ?». Говорить про то, что в схеме отделов и департаментов компании, которая приводится в отчете бизнес-аналитика, данный отдел отсутствовал – думаю, нет надобности.

На следующий день, с утра наведываюсь на задворки компании, и на второй же фразе начальник отдела спрашивает «а кто тебе дал эти товары? Мы их уже 3 года как не производим»? Занавес.

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

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

В итоге, взглянув на Сафед-диаграммы, менеджер, или другой специалист сразу видит всю необходимую ему информацию по процессу. Более того, часто будут заметны недостатки текущего процесса, его описания или же того, что предлагает бизнес-аналитик. С другой стороны, при изменении технических средств, которые мы или заказчик применяет в рамках процесса (внутренняя система электронного документооборота, физические носители данных и т.д.) сама диаграмма процесса не меняется. И это, с моей точки зрения, достаточно большой плюс, поскольку мы описываем логику процесса, а не его реализацию. Более того, в дальнейшем, при сравнении рекомендаций, всегда можно оценить, не менялась ли логика процесса, все ли связи, взаимодействия, оповещения и проверки были реализованы.
В принципе, нечто похожее можно изобразить и в рамках BPMN, EPC и UML. Однако рекомендации для этих нотаций больше ориентированы на описание конкретных реализаций процессов, а не на их логику. Я надеюсь, что все понимают, что идея в том и состоит, чтобы применять подобные Сафед-диаграммы как дополнение, как отправную точку для анализа процессов «As Is» и «To Be», а не как замену этих диаграмм.

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

У меня все. Надеюсь, кто-то найдет для себя что-нибудь полезное.

Всем удачи и успехов.

Песик с газеткой

Источники изображений:
1. Песик и «бардак на почте» — отсюда и отсюда, соответственно.
2. Диаграмки — личное творчество.
ссылка на оригинал статьи https://habrahabr.ru/post/327370/

Kali Linux 2017.1

image
 
Долгожданный релиз Kali Linux 2017.1! Состоятся rolling-release Kali Linux 2017.1, который содержит множество интересных обновлений и функций: обновленные пакеты, обновленное ядро, которое обеспечивает более качественную аппаратную поддержку, а также множество обновленных инструментов и нововведений.

Kali Linux представляет из себя дистрибутив, содержащий множество утилит для проведения тестирования на проникновение — от анализа уязвимостей веб-приложений, до взлома сетей и сервисов и закрепления в системе. Ранее этот дистрибутив был известен под названием Backtrack.

Что нового?

Поддержка беспроводных плат RTL8812AU

Разработчики дистрибутива получали множество запросов запрос о включении драйверов для беспроводных чипсетов RTL8812AU. Эти драйверы не являются частью стандартного ядра Linux и были модифицированы для обеспечения возможности инжекта пакетов в стандарте 802.11 AC.

Оптимизированная поддержка CUDA GPU Cracking

Установка пропиетарных графических драйверов всегда была источником разочарования в Kali. В новом дистрибутиве это недостаток устранен: теперь можно нативно задействовать графические процессоры NVIDIA в при использовании Hashcat и Pyrit.

OpenVAS 9

Популярный сканер OpenVas 9 теперь в Kali Linux. Небольшое «но» — не из коробки, но из репозиториев.

Дистрибутивы

Дистрибутивы доступны в виде ISO образов для платформ x64, x32, ARM; с графическими оболочками Gnome, XFCE и т.д.; в виде образов виртуальны машин VirtualBox и Vmware.

UPD:
Сервера Kali не справляются с нагрузкой, поэтому на DefconRU размещены скоростные зеркала:
Скачать Kali Linux 2017.1
ссылка на оригинал статьи https://habrahabr.ru/post/327378/

Как правильно настроить межсетевой экран или Check Point Security Best Practices


Уверен, что у большинства системных администраторов или сетевых инженеров возникал вопрос: "Правильно ли я настроил межсетевой экран и что еще можно сделать для лучшей защиты?". Естественно, в этом вопросе стоит опираться на различные руководства (PCI DSS, ISO, NIST и т.д.) и здравый смысл. Помощь более опытных коллег также приветствуется.
В рамках же данной статьи мы попробуем описать основные рекомендации или лучшие практики (best practices) по настройке межсетевых экранов. Это некий “чек-лист”, следуя которому можно существенно повысить качество защиты сети. Руководство составлено специально для оборудования Check Point, однако оно также может быть использовано, как основа для самостоятельного аудита сети, построенной на оборудовании других вендоров (Cisco, Fortinet, Palo Alto и т.д.). Если вас это заинтересовало, то добро пожаловать под кат…

Compliance Blade
Вообще говоря, в случае с Check Point аудит «правильности» настроек можно выполнять в автоматическом режиме. Осуществляется это с помощью программного блейда Compliance, который активируется на менеджмент сервере:

Данный блейд выполняет следующие функции:

  1. Мониторинг программных блейдов в режиме 24/7
    • Постоянный контроль за тем, чтобы система управления, программные блейды и шлюзы безопасности были настроены оптимально.
    • Показывает неправильные настройки конфигурации и уязвимости в защите.
    • Предоставляет рекомендации по укреплению безопасности.

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

  3. Готовые отчеты
    • Переводит тысячи требований регуляторов на язык практических рекомендаций.
    • Постоянная оценка совместимости с требованиями регуляторов (PCI DSS, ISO, NIST, DSD и так далее).

Все отчеты отображаются в графическом виде:
Оценка настроек

Оценка соответствия требованиям регуляторов

Оценка производительности отдельных шлюзов и блейдов

Блейд Compliance поставляется бесплатно с подпиской на 1 год при покупке сервера управления (будь то физический appliance Smart-1 или виртуальная машина). Этого времени вполне достаточно для комплексной настройки средств защиты с последующей оценкой конфигураций. Таким образом, в первый год вы получаете бесплатный аудит сетевой безопасности (настроек Check Point).
Если вы еще ни разу не активировали данный блейд, то это весьма просто сделать в свойствах сервера управления (Management Server), как это было показано на картинке выше. После этого проинсталлировать политики и подождать некоторое время (в зависимости от размеров сети и количества шлюзов). С результатом оценки конфигураций можно ознакомиться на соответствующей вкладке Compliance в консоли SmartDashboard:

Стоит заметить, что дальнейшее использование блейда Compliance требует продления соответствующей подписки, цена которой не всегда соответствует бюджету малых и средних компаний.
Что же делать после окончания подписки?
Специально для таких случаев мы создали данное руководство, которое позволит в ручном режиме проверить “адекватность” и безопасность текущих настроек в соответствии с рекомендациями Check Point. При этом мы не будем рассматривать стандарты различных регуляторов (PCI DSS, ISO и т.д.), а лишь затронем лучшие практики (Best Practices) по настройке средств сетевой защиты.

Firewall Best Practices
1. Присутствует правило Management (название может отличаться):

Данное правило используется для доступа с сервера управления (Management Server) и компьютера администратора к шлюзу безопасности (Security Gateway). Остальным доступ должен быть запрещен.

2. Присутствует правило Stealth (название может отличаться):

Данное правило используется для блокирования любой попытки доступа к самому шлюзу, что делает его “невидимым” и исключает возможность несанкционированного доступа. Убедитесь, что это правило расположено ниже чем Management.

3. Присутствует правило Clean up rule (название может отличаться):

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

4. Присутствует правило Do Not Log (название может отличаться) для которого отключено логирование:

Данное правило используется для фильтрования “паразитного” широковещательного трафика. К такому трафику относятся: udp-high-ports (UDP ports > 1024-65535), domain-udp, bootp, NBT (NetBios), rip (список может отличаться, в зависимости от вашей сети). Логирование отключается намеренно, дабы не перегружать логи межсетевого экрана бесполезной информацией. Правило должно находиться как можно выше в списке (лучше первым).

5. В списках доступа в колонке источник (source) отсутствует значение Any, т.е. любой трафик. Всегда указывайте конкретный источник в правилах, будь то сеть или хост. За исключением правил Stealth, Clean up rule, Do Not Log.

6. Отсутствуют правила разрешающие весь трафик (any any accept).

7. Запрещен входящий Internet трафик для сегментов Бухгалтерии (Finance) и Отдела кадров (HR).

8. Запрещен FTP трафик из сети Internet в DMZ.

9. Отсутствуют неиспользуемые правила. В консоли SmartDashboard можно просматривать счетчик совпадений по каждому списку доступа:

Если счетчик показывает нулевое значение или последнее совпадение (Last hit) было более чем 6 месяцев назад, то рекомендуется удалить данное правило, дабы не перегружать общий список.

10. Для всех правил в поле Track выставлена опция Log. Кроме правила Do Not Log. Так вы сможете логировать все важные события исключая широковещательный трафик.

11. Для всех правил указано “адекватное” имя и присутствует комментарий, поясняющий назначение этого правила.

12. На всех шлюзах включено логирование.

В качестве Лог-сервера может выступать сервер управления (Management Server) либо другое стороннее решение (возможно использование SIEM или Log Management систем).

13. На всех шлюзах настроен резервный Лог-сервер. Это позволит сохранить важные сообщения в случае отказа основного Лог-сервера.

14. На всех шлюзах также включена функция локального хранения логов. Это позволит сохранить информацию о событиях в случае недоступности Лог-сервер.

15. На всех шлюзах настроено создание нового Лог-файла при достижении определенного размера старого.

Это значительно ускорит обработку логов (отображение, поиск). Вернуться к более старым логам можно будет переключив Лог-файл.

16. На всех шлюзах настроены уведомления сигнализирующие о заканчивающемся дисковом пространстве. Уровень срабатывания выбирается в зависимости от общего объема жесткого диска. Как правило порог выставляется в районе 50-100 МБайт.

17. На всех шлюзах настроено удаление старых Лог-файлов при заканчивающемся дисковом пространстве. Уровень срабатывания выбирается в зависимости от общего объема жесткого диска. Как правило порог выставляется в районе 50 МБайт.

18. На всех шлюзах настроены скрипты, которые выполняются перед удалением старых Лог-файлов.

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

19. В глобальных настройках включено логирование для “VPN packet handling errors”, “VPN successful key exchange”, “VPN configuration & key exchange errors”, “Administrative notifications”, “Packet is incorrectly tagged” и “Packet tagging brute force attack”:

20. На всех шлюзах включен Anti-Spoofing в режиме prevent (для всех интерфейсов):

21. В глобальных настройках (global properties) проверьте значения временных интервалов по умолчанию для stateful inspection:

В случае необходимости измените в соответствии с требованиями вашей сети.

22. Для полей “Drop out of state TCP packets”, “Drop out of state ICMP packets” и “Drop out of state SCTP packets” включено Log on drop (смотри картинку выше).

23. В свойствах каждого шлюза включен счетчик Hit Count:

Это позволит видеть кол-во совпадений по каждому правилу (списку доступа) и удалять неиспользуемые.

24. В настройках оптимизации шлюза укажите максимальное количество конкурентных сессий.

Этот параметр зависит от модели шлюза и позволяет предотвратить перегрузку.

25. В глобальных настройках (global properties) пароли учетных записей пользователей (User Accounts) и администраторов (Administartor Accounts) истекают не позднее чем через 180 дней.

Также должно быть настроено оповещение об истекающем пароле.

26. При интеграции с Active Directory настроена смена пароля:

27. В глобальных настройках (global properties) активирована блокировка Администраторов. Учетная запись блокируется на 30 минут в случае 3-х неудачных попыток входа.

Также настроено уведомление о блокировке и сброс сессии управления, неактивной в течении 15 минут.

28. В свойствах шлюзов выставлена опция “Rematch connections”.

Это позволит блокировать запрещенные соединения сразу после установки новой политики и не ждать окончания сессии.

29. Настроена синхронизация времени (NTP)

Это позволит видеть актуальную дату и время для всех событий (логов).

Таковы рекомендации Check Point по настройке блейда Firewall. Но думаю многие заметили, что большинство советов применимы и к другим вендорам. Подобные рекомендации есть по всем блейдам (IPS, DLP, Application Control, URL Filtering и т.д.), которые мы возможно рассмотрим в следующих статьях.
ссылка на оригинал статьи https://habrahabr.ru/post/327316/