Русский
Русский
English
Статистика
Реклама

Mdm

Recovery mode Зачем нужны сертифицированные средства защиты информации?

02.11.2020 22:09:30 | Автор: admin

Сертификат справка очень важная, но слегка бумажная.
Что она даёт, кому и зачем она нужна пытаемся разобраться под катом.

Что даёт сертификация?

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

В области сертификации средств защиты информации в России два основных регулятора ФСТЭК и ФСБ. ФСБ занимается, в основном, сертификацией криптографических средств, а остальные средства защиты информации (не)нужно (обсудим дальше) сертифицировать во ФСТЭК.

Для сертификации типовых средств защиты, таких как межсетевые экраны или антивирусы, ФСТЭКом разработаны наборы специализированных требований. Остальные средства проходят сертификацию на соответствие техническим условиям или заданиям по безопасности, а набор функций безопасности определяется разработчиком продукта. Это чем-то напоминает советскую тушёнку по ГОСТ и по ТУ, но в ряде случаев ГОСТов попросту нет.

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

Придётся разобраться в продукте и в технологии его разработки

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

Придётся не только найти у себя функции безопасности, но и показать, как именно они работают и какие исходные тексты соответствуют этим функциям. Тем, кто хочет приблизить себя к защите государевой тайны ещё придётся пройти занимательные квесты с фаззингом и другими весёлыми инструментами от инженера Джона Крамера. Холодный пот и бессонные ночи вам обеспечены, но зато свой код будете помнить от main () до ..лЯ!.

Кроме анализа кода вам предстоит сдать анализы от процесса разработки, описать свой gitflow, процесс CI, исправление багов, доставку исправлений клиентам и т.д.

Разработка средств безопасности должна быть безопасной и не должна быть опасной. О как!

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

Что общего между сертификаторами и Лангольерами

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

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

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

Сначала вам надо доказать и детально описать соответствие заявленных функций испытательной лаборатории, а потом вместе с испытательной лабораторией предстоит выдержать сто тысяч ПОЧЕМУ от ОРГАНА по сертификации. На каждом шагу может быть Nили даже Kитераций. Короче, будет Nепросто, а иногда Капец, как долго.

НаучИтесь натягивать сову на глобус

Руководящие документы (РД) это вам не гайдлайны и обучающие видео от Google. Читать РД могут не только лишь все, а только лишь те, кто умеет переводить с казенного на русский без словаря. Большинство испытательных лабораторий успешно справляются с этой задачей. Но, увы, остаются и те, кто цитирует РД как ПисАние. Поэтому при выборе лаборатории ищите ту, у представителей которой при слове руководящий документ глаза не загораются в религиозном экстазе. Иначе есть шанс попасть в филиал Святой Инквизиции, целью которой является ярко и с огоньком обращать неверных в верных.

Причём тут сова и глобус? - спросите вы. А при том, что с учётом даты выпуска части действующих РД (начало конца XXвека), в которых определены основные термины и определения, успех сертификации иногда зависит от правильной трактовки требований и умения обосновать свою позицию.

Испытательная лаборатория должна быть вашим партнёром, а не истязателем. В общем, тщательно выбирайте партнёров. Иначе на глобус натянут вас.

Кому нужны сертифицированные продукты?

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

Всё просто. Несертифицированные средства использовать или запрещено, или не рекомендуется. Государственные информационные системы (ГИС) нельзя ввести в действие без аттестации на соответствие требованиям безопасности. А аттестацию в свою очередь можно провести, только если требования безопасности реализуются за счет сертифицированных средств защиты.

Чем не игла в яйце?

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

Короче, не ходите сюда, самим мало

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

Кому нужна сертифицированная система защиты и управления мобильными устройствами?

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

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

Рассмотрим, например, гипотетический проект Цифровой фрезеровщик.

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

А сервер ГИС за это будет возвращать на смартфон рекомендации о том, как заточить фрезу, когда можно сходить по нужде и др., чтобы получить 13-ю зарплату.

Итак, нам нужно сдать цифровой прожект. Для этого его нужно аттестовать. И тут у нас есть только два пути:

  1. Реализовать функции безопасности в своём ПО и сертифицировать его. На это нужен год и специально выделенные люди, которые будут жертвовать свои человеко-часы на алтаре процесса сертификации. Иногда так делают, но чаще идут по второму пути.

  2. Купить сертифицированные средства защиты, которые выполнят требования, необходимые для аттестации.

Для успешной аттестации ГИС на практике хватает следующего комплекта сертифицированных средств защиты для мобильных устройств:

  1. VPNс ГОСТ шифрованием. Подойдёт любой с сертификатом ФСБ России.

  2. MDM/ EMM/ UEMс сертификатом ФСТЭК России.

  3. Антивирус с сертификатом ФСТЭК России.

А сейчас рекламная пауза!

Единственным сертифицированным MDM/ EMM/ UEMрешением для Androidи iOSявляется наша платформа SafePhone. Конечно, цифровому фрезировщику iPadне светит. Но если начальник из профильного ведомства, угодивший на принудительную удалёнку, захочет получить доступ с iPadк рабочим файлам без их пересылки на личный почтовый ящик Google, ему придётся аттестовать ГИС удалённого доступа и тут мы ему поможем.

И ещё одно. Чтобы оптимизировать затраты своих заказчиков, мы недавно встроили в свою платформу антивирусные библиотеки Лаборатории Касперского. Теперь, чтобы удовлетворить регулятора, нужно покупать на одно решение меньше. Встречайте SafePhone MTD Edition.

Подробнее..

Отключение профиля MDM на Mac OS Big Sur

29.12.2020 12:11:44 | Автор: admin

Немного про MDM

MDM (англ. Mobile Device Management) профиль, как правило, устанавливается пользователям на устройства, которые выданы им крупными компаниями, а также некоторыми школами и университетами в пользование. MDM профиль позволяет автоматизировать настройку практически всех программных компонентов устройства. При этом он также позволяет полностью контролировать устройство дистанционно. Возможности контроля ограничены лишь фантазией администратора, который его настраивал.

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

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

Решение с обходом MDM блокировки на Mac OS Catalina достаточно прямолинейное и без труда находится в интернете. С Big Sur все намного сложнее. В новой операционной системе реализован новый механизм защиты целостности системы. Поэтому весь алгоритм действий усложнился.

Установка чистой системы

Будем предполагать, что мы в состоянии сами установить чистую систему Mac OS Big Sur с флешки. В случае с MDM устройством главное правило - проводим чистую установку с отключенным интернетом, чтобы система не могла получить данные по имеющемуся MDM идентификатору.

После завершения установки к интернету подключаться можно. К сожалению, система тут же начнет предлагать загрузить и установить тот самый MDM профиль, который по ее мнению должен быть настроен в системе. Настойчивость таких предложений - примерно раз в 10 минут. Жить можно, но мы не согласны на полумеры.

Отключение MDM профиля

1. На устройстве должен быть снят пароль на включение и выключено шифрование диска:
Настройки -> Безопасность -> FileVault - выключить

2. Перезагружаемся в режиме восстановления:
Удерживаем (Command+R) во время загрузки до появления полосы загрузки.

3. В режите восстановления запускаем терминал:
"Утилиты" -> "Терминал"

4. Смотрим индентификатор тома:

mount

5. Если вы не трогали название разделов во время установки, то название по умолчания должно остаться "Macintosh HD". Здесь и далее будем использовать его.


Записываем на листик индентификатор тома "/Volumes/Macintosh HD"

Внимание! Не перепутать с диском "/Volumes/Macintosh HD - Data"
Идентификатор выглядит примерно так dev/disk4s5 - в вашем случае цифры могут быть другие.


Внимание! Индентификатор тома и название тома в последующих примерах команд подставляем свои!

6. Отключаем том и копируем файлы агентов в отдельную папку bak:

umount /Volumes/Macintosh\ HDmkdir /Volumes/Macintosh\ HDmount -t apfs -rw /dev/disk2s5 /Volumes/Macintosh\ HD cd /Volumes/Macintosh\ HD/System/Library/LaunchAgents mkdir bakmv com.apple.ManagedClientAgent.* bak/ mv com.apple.mdmclient.* bak/cd ../LaunchDaemons mkdir bakmv com.apple.ManagedClient.* bak/ mv com.apple.mdmclient.* bak/

7. Отключаем Signed System Volume (SSV):

csrutil authenticated-root disable

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

bless --folder /Volumes/Macintosh\ HD/System/Library/CoreServices --bootefi --create-snapshot

9. Закрываем терминал и перезагружаемся.

Готово. Агенты MDM профиля больше системой не видятся.


Обновления будут работать. Если сделать чистую переустановку - процедуру придется повторить сначала. Иногда фикс слетает после установки мажорных обновлений.

Работоспособность метода проверена на Mac OS Big Sur до версии 11.1.

Подробнее..

Обзор решения Proget MDM

14.05.2021 14:06:19 | Автор: admin

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

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

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

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

Рассмотрим основной функционал системы Proget MDM:

Контроль мобильных устройств

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

Управление приложениями

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

Настройка корпоративной среды

Автоматическая настройка корпоративных сервисов, таких как электронная почта, календарь, контакты, сети Wi-Fi, подключения к VPN, передача файлов и прочего. К слову, Proget MDM позволяет передавать файлы корпоративным пользователям на их устройства по защищенному шифрованному каналу через собственное приложение.

Отслеживание местоположения

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

Удаленное подключение

Встроенные в приложение Proget MDM средства удаленного подключения позволяют специалистам ИТ-подразделения оперативно оказывать помощь сотрудникам компании и устранять любого рода проблемы, исключая трату времени на разъяснения по телефону.

Очистка корпоративных данных

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

Интеграция с Active Directory

Система Proget MDM с лёгкостью интегрируется с корпоративной службой каталогов Active Directory по протоколу LDAP, что значительно упрощает её внедрение. Мобильные устройства возможно привязать к текущим учётным записям, упрощая тем самым взаимодействие с пользователями.

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

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

Proget MDM предоставляется в двух версиях: в облаке и так называемом on-premise. В первом случае система размещена на мощностях производителя, и всё, что вам необходимо это пройти регистрацию, после которой вы получаете доступ к демо-стенду, готовому к настройке, лицензированию, и последующей работе. Преимуществом данного подхода является простота развёртывания и сроки запуска, а также отсутствие головной боли по поводу отказоустойчивости сервиса. Недостаток здесь только один хранение корпоративной информации у третьих лиц. Ни для кого не секрет, что размещение сервисов на собственных ресурсах обеспечивает больший контроль над сохранностью конфиденциальной составляющей данных. Наши специалисты на личном опыте прошли все этапы подготовки и развертывания системы и готовы помочь спроектировать необходимые ресурсы и внедрить Proget MDM.

На подконтрольные устройства Proget MDM ставится по-разному, в зависимости от выбранного типа интеграции. Например, на личном смартфоне сотрудника можно быстро установить приложение Proget MDM прямо из Play Market, ввести учётные данные и готово. В случае с корпоративным смартфоном, настройка может заключаться в полном сбросе устройства с последующей неразрывной интеграцией Proget MDM. Для более прозрачного понимания взаимодействия системы с устройствами пройдёмся по типам интеграции (активации) доступных в решении Proget MDM:

Android MDM

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

Android Enterprise - Work Managed Device

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

Android Enterprise - Work Managed Device

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

К типам активаций, использующих аналогичный метод контейнеризации, относятся также Samsung Knox MDM и Samsung Knox Container. Данные интеграции максимально раскрывают богатые возможности Proget на устройствах компании Samsung.

iOS MDM

Тип активации, близкий по концепции к Android MDM, но при этом обладающий меньшим функционалом по воздействию на мобильное устройство. Обусловлено это политикой Apple, с чем разработчикам и пользователям приходится лишь смириться. При этом, iOS MDM предоставляет более расширенные возможности в плане тонких настроек системы и профилей безопасности. Контейнеризация не поддерживается. Интеграция не видоизменяет персонализацию устройства пользователя.

Windows MDM

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


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

Подробнее..

Мобильные контейнеры для раздельного хранения данных

07.06.2021 12:06:42 | Автор: admin

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

Но и эта медаль двухсторонняя. Сотрудники требуют гарантий, что работодатель не читает их переписку или не смотрит их фотографии. Работодатели в свою очередь против того, чтобы сотрудники делились корпоративными документами в социальных сетях или передавали их в СМИ.

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

Зачем нужен контейнер работодателям и их сотрудникам?

Работодатели и сотрудники хотят, чтобы контейнер защищал ИХ секреты. Только секреты каждой из сторон находятся по разные стороны контейнера секреты работодателя находятся внутри контейнера, а секреты сотрудника снаружи.

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

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

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

Особенность контейнеров для iOS

В своей прошлой статье мы убеждали читателя, что iOS это закрытая экосистема, которую нужно принимать такой, какая она есть. Контейнеры на iOS ещё одно тому подтверждение.

С точки зрения контейнеризации в iOS есть встроенный механизм разделения корпоративного и личного. Apple называет корпоративное управляемым (managed), а личное неуправляемым (unmanaged).

Управляемыми в iOS могут быть приложения, учётные записи и URL в Safari. С помощью встроенных политик можно запретить передачу данных между управляемым и неуправляемым, но только случайную. Это значит, что сотрудник не может передать вложение из корпоративной почты в личную почту или в WhatsApp, но может скопировать текст вложения и вставить его куда угодно!

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

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

Разнообразие Android - контейнеров

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

Первой компанией, которая сделала возможным создание контейнеров на Android, стала компания Samsung. В 2012 году на смартфоне Samsung Galaxy S3 впервые стали доступны функции корпоративной платформы безопасности Samsung Knox. В частности, Knox контейнеры. Большинство современных устройств Samsung также их поддерживают. Многие функции платформы Samsung Knox бесплатны, но функции Knox контейнеров были платной опцией. Позже Google анонсировал свою бесплатную корпоративную платформу Android for Enterprise c меньшим набором функций.

С годами число функций управления контейнерами, которые были эксклюзивно доступны на устройствах Samsung, сокращалось, потому что они появлялись у Google. В результате, начиная с
1 июля 2021 года, Samsung принял решение о бесплатном предоставлении возможностей Knox-контейнеризации. В составе платформы Samsung Knox ещё остаются платные опции, которых нет у Google. Например, корпоративных сервис обновления прошивок мобильных устройств E-FOTA One, о котором мы рассказывали в одной из прошлых статей.

Но конкретно Knox контейнеры отныне бесплатны.

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

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

Вроде то, что нужно? Да, но не обошлось без важных особенностей.

В составе Samsung Knox есть клиентские библиотеки для Android, с помощью которых можно разработать клиент управления, который сам создаст контейнер, применит в нём необходимые политики безопасности и наполнит его приложениями.

Работает эта схема так:

  1. На мобильное устройство устанавливается клиент управления.

  2. Пользователь регистрирует устройство на сервере управления.

  3. Клиент управления создаёт и настраивает контейнер для работы. После чего периодически спрашивает у сервера управления, не изменились ли эти настройки.

  4. Можно доставить обновления настроек быстрее с помощью push-уведомлений от Google, но их использование необязательно.

Преимущество этой схемы в том, что её можно построить в локальной инфраструктуре заказчика (on-premise). Для крупного бизнеса в России это важно.

У платформы Android for Enterprise от Google тоже есть клиентские библиотеки и с их помощью можно управлять устройствами без контейнеров устанавливать приложения, настраивать ограничения и т.д. Даже можно создать контейнер, поместить в него встроенный Gmail или Google Chrome и запретить сотруднику копировать из контейнера файлы. Всё это будет работать on-premise.

Но клиентские библиотеки Google не помогут, если нужно разместить в контейнере приложение собственной разработки или какое-то приложение из Google Play. В этом случае необходимо использовать Android Management API, который работает по несложной схеме:

  1. На мобильное устройство устанавливается клиент управления от Google Android Device Policy.

  2. Администратор создаёт настройки контейнера какие приложения в него установить, какие политики ограничений применить и т.д.

  3. Сервер передаёт настройки контейнера в Google с помощью Android Management API. Дальше Google обеспечивает их применение на устройстве самостоятельно. При этом все команды и все дистрибутивы корпоративных приложений нужно передать в Google.

    Источник: https://developers.google.com/android/management/introductionИсточник: https://developers.google.com/android/management/introduction

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

Корпоративный Android в личном пользовании

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

Начиная с Android 11, нельзя одновременно управлять и контейнером, и тем, что находится вне его. Это сделано, чтобы исключить доступ работодателей к личным данным сотрудников.
Цена приватности оказалась достаточно высокой. Теперь на корпоративных устройствах с контейнером нельзя определять геолокацию, устанавливать приложения вне контейнера и проверять устройство на наличие вирусов.

Источник: https://docs.samsungknox.com/admin/knox-platform-for-enterprise/work-profile-on-company-owned-devices.htmИсточник: https://docs.samsungknox.com/admin/knox-platform-for-enterprise/work-profile-on-company-owned-devices.htm

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

Knox Separated Apps, как и Knox контейнеры, с 1 июля 2021 года также станет бесплатной.

Советы для топ-менеджеров

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

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

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

На каждом новом устройстве корпоративный софт не работает совершенно особенным образом. Каждая мажорная версия Android c 4 по 12 серьёзно отличаются. У каждого производителя своя сборка Android. У каждой сборки Android, особенно китайской, свои тараканы неуправляемые менеджеры памяти и батареи, которые так и норовят поскорее закрыть приложение или не дать ему вовремя получить данные от сервера, дополнительные разрешения, которые пользователь должен вручную дать приложению и которые он может в любой момент отобрать и т.п.

Если планировать мобилизацию компании на 3-5 лет вперёд, дешевле выбрать несколько моделей устройств, и дальше проверять и разрабатывать корпоративный софт (клиент документооборота, приложения с BI-отчётностью, мессенджеры и т.п.) на этих конкретных моделях. Всё-таки корпоративный софт пишут не тысячи разработчиков Facebook по всему миру. Поэтому чем меньше вариативность устройств, тем меньше ошибок, тем меньше число уязвимостей и ниже вероятность их успешной эксплуатации. Короче, всем удобнее и безопаснее.

Если у вас возникли вопросы или сомнения после прочтения статьи, напишите о них в комментариях.

Подробнее..

Recovery mode Создаём компанию мечты мастер-данные и интеграция

03.03.2021 00:13:52 | Автор: admin
Есть легенда, что когда Билл Гейтс с коллегами продумывали архитектуру будущей Windows 3.1, они рисовали её от руки на склеенных ватманах. Маленькие квадратики обозначали блоки и модули системы, а стрелочки между ними потоки данных из одной системы в другую. Эта схема поместилась целиком на полу в кабинете у самого Гейтса, правда, пришлось вынести в коридор стол и стулья.

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

image

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

Интеграция

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

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

image

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

В этой статье я хочу описать основные этапы процесса, как он обычно стихийно складывается в крупных компаниях. Ввести шкалу интеграционного развития компании от 1 до 10. Эта шкала, конечно, будет отражать и сам рост компании, рост уровня развития административных технологий в компании. А также хочу наметить основные векторы развития: куда бежать, что делать и кто во всём этом виноват. Шутка.

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

Также в статье почти нет названий конкретных продуктов или технологий, т.к. в области интеграции нет дорог, есть направления. Нет конкретного продукта, который просто поставил и пользуешься. Речь всегда будет идти о разработке, как минимум, коннекторов. Упоминаются 1С, Windows, Office как широко распространённое ПО, но вместо них без потери смысла можно подставить SAP, Linux и т.д.

Конечно, примеры упрощены в целях наглядности. Несколько вопросов останутся открытыми. И сам подход, как это всегда бывает в IT, не является единственно верным, поэтому приглашаю всех к дискуссии.

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

Уровень 0

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

Чтобы платить налоги (если у вас не вменённый доход), вам нужно как-то посчитать, сколько денег вы всего заработали за период. Маловероятно, что ИП сразу начнёт работать по безналу, а при работе с налом с недавних пор в России требуется кассовый аппарат.

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

Так на вашем ноутбуке появляется простенькая 1С-ка или любой другой аналогичный продукт.

image

image


Уровень 1: отрицание

Бизнес идёт отлично, у вас появился помощник, затем ещё один.

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

Вы читаете инструкцию к кассе, настраиваете подключение через мобильный интернет. Либо обращаетесь в компанию, где купили её, там вам с удовольствием помогают. Про какую-либо интеграцию речи пока не идёт.

image

image


Уровень 2

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

И ещё один договор, третий, с поставщиком, а то как-то с устными договорённостями о поставках у него не очень: нарушает сроки, есть вопросы по качеству.

С первым клиентом вы смогли договориться на предоплату, а второй убедил вас на постоплату, и вам теперь нужно вести учёт в разрезе клиентов, чтобы точно понимать, кому сколько было взвешено в граммах. К счастью, в вашей 1С есть справочник контрагентов, и вы торжественно занесли в него две первые записи. Ещё своего поставщика, на всякий случай. И ещё одну прочее.

После вчерашней вечеринки у вас разболелась голова. Вы сходили в банк за выпиской по счету и обнаружили там свой первый приход! Конечно, такой повод нельзя было пропустить и не отметить. И тут вы задумались, а что если однажды ваш бизнес вырастет настолько, что платёжки будут приходить каждый день?

image


Уровень 3: гнев

Несколько раз всё чуть не пропало. Обязательства заставили вас сильно изменить свой бизнес. Проблемы начали возникать, в общем-то, в самых простых вещах. Там, где вы их точно не ждали.

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

Обо всём договорились, назначили самого смышлёного из сотрудников своим заместителем, сказали, чтобы звонил, если что-то пойдёт не так и уехали отдыхать на две недели.

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

Затем раздался звонок. Нет, не так. ЗВОНОК. Не так пошло не только лишь всё, вам пришлось в срочном порядке возвращаться домой и восстанавливать всё, что без вас чуть не поломали: отношения с клиентами, процессы, учёт.

С самым смышлёным пришлось расстаться, а для себя вы сделали два вывода:

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

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

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

Недавно нанятый менеджер привел в компанию толковую бухгалтершу пока на неполный рабочий день, конечно. Она же объяснила, что для работы вам нужно будет заказать у франчайзи 1С разработку пары отчётов, без которых вот совсем никак. Также она взяла на себя расчёт зарплаты и кадровое делопроизводство, только начала вести их не в 1С, а в другой программе, которой их учили в колледже.

image

image


Уровень 4

Прошло ещё несколько лет. Были взлёты, были падения, было всякое. В стране отгремел кризис, но вас как-то особо не затронул. В том числе благодаря тому, что вы всегда чётко понимали состояние своего бизнеса, и могли оперативно резать косты там, где это необходимо.

У вас сформировалась репутация надёжного партнёра, число клиентов превысило 20, а в компании трудится уже около 50 человек. Появилось несколько отделов!

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

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

Начали думать о программе для управления складом и поставками (было пару кейсов увезли товар не тому клиенту), но 1С-ник подсказал, что можно купить модуль склада для 1С. Или вообще ничего не покупать, он сам напишет лучше и именно с учётом ваших потребностей.

Ещё вы несколько раз перепутали скидки, которые обещали разным клиентам, а недавно вообще выставили счёт на несколько миллионов не тому клиенту, из-за чего он сильно напрягся. Все сотрудники как один твердят, что пришла пора внедрять CRM.

Паренёк-айтишник недавно закончил университет и предложил написать свою CRM, которая включала бы в себя и весь ваш производственный цикл. 1С-ник обещал ему помочь. И буквально за пару недель они набросали работающий прототип, им вполне можно было пользоваться!

Оба говорили и вели себя достаточно уверенно, и в этот момент вы серьёзно задумались: развивать ли свою собственную IT-службу, разрабатывать ли собственные решения или обратиться к какому-нибудь интегратору, воспользоваться услугами аутсорсинга?

Порядком подумав, выслушав и прочитав множество мнений, вы решили не выбирать аутсорсинг. Во-первых, он почти всегда дороже, чем сотрудники в штате, т.к. с него кормятся не только исполнители, но и их руководство, и ещё платится множество налогов.
Во-вторых, далеко не всегда гарантируется качество такой работы, даже если исполнители самые титулованные (в неформальной обстановке вы как-то раз спросили у них про процент успешно и вовремя выполненных проектов, ой, зря)
И, в-третьих, и это самое критичное: ни один аутсорсер не будет вам делать работу как для себя. Это противоречит его бизнес-интересам привязать вас к себе всеми возможными способами.

В итоге, вы поверили убедительным голосам своих айтишников и решили, что так будет лучше, иметь свои собственные разработки! Понятно, что позже понадобится взять ещё разработчика и не одного. Понятно, что они будут косячить со сроками, что будут делать не то, что будут отвлекаться. Тут главное, чтобы руководитель был толковый. А нюансы так они у всех нюансы, есть они и в бухгалтерии, и у охраны, и в АХО.

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

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

image

image


Уровень 5: торг

С ростом бизнеса был открыт офис в соседнем областном центре, потом в северной столице. Настал очередной критический момент в развитии бизнеса и компании региональное масштабирование.

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

После нескольких инцидентов с утечкой информации вы решаете нанять специалиста по ИБ. Он, конечно, переворачивает вверх дном почти всю IT-инфраструктуру и завоевывает искреннюю любовь всех айтишников. К счастью, временно, т.к. умеет наглядно обосновывать свои требования, да и, в целом, сам айтишник, одной с ними крови. Первым его требованием было закрыть все ненужные порты и направить информацию по защищённым каналам. Он дал много добрых советов по мониторингу, бэкапам, защищённости, другим полезностям, но самое главное в контексте этой статьи принёс в компанию ещё пару информационных систем, которые нужно было интегрировать с остальными. Всего их у вас получилось уже 7-8.

Недавно был запущен корпоративный портал, интранет, он стал хорошим помощником для сотрудников. Однако, самым большим откровением для вас стало то, что на портале не получилось вывести структуру компании и список сотрудников. Нет, ребята что-то показали, но что это за структура, где они её взяли? Это просто какой-то гибрид ужа и ежа! А список сотрудников? Вы лично увольняли нескольких из них, почему они до сих пор показываются? Они есть в кадровой системе? А в 1С? Откуда эти данные?..

Разработчик 1С *) вышел с предложением купить и внедрить модуль для учёта мастер-данных это когда вся информация по всем общим справочникам (например, по структуре, сотрудникам, контрагентам) собирается и контролируется в одной системе. А также чтобы все обмены информацией шли через эту систему, тогда этот процесс будет наглядным и управляемым. Если будут какие-то ошибки, их сразу заметят а это особенно важно. Пару месяцев назад уже был прецедент, когда информация о зарплате не выгрузилась из кадровой системы в 1С, и зарплату сотрудникам не перечислили вовремя.

Что для этого нужно? Выбрать такую систему. Разработчики советуют решение на платформе 1С это конструктор, который нужно дорабатывать для себя. Будущее этого решения пока не очень понятно, но обоснование его нужности звучит понятно и логично. Берём!

*) повторю, что 1С здесь только для примера. Решения класса MDM (управление мастер-данными) и ESB (интеграционная шина предприятия) доступны почти у всех платформ и вендоров. Это может быть и SAP, IBM, Oracle, и бесплатные решения Fuse, Mule и др.


image

image


Уровень 6

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

Главный вопрос в планировании IT-ландшафта и интеграции на этот момент есть ли возможность каждой информационной системе работать для всех стран одновременно? На практике у каждой системы оказались свои нюансы. Бухгалтерская и кадровая системы их нужно вести строго в разных базах. MDM и ESB пришлось доработать таким образом, что в большинстве справочников появилась страновая привязка. Причём некоторые элементы (например, ФИО, должности, названия контрагентов) пришлось хранить сразу на нескольких языках.

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

На самом деле, вы довольны ситуацией в IT и IT-командой. Заложенные когда-то основы позволили без особых трудностей и стоп-факторов осуществить экспансию. Трудно представить, сколько сил и ресурсов у вас ушло бы сейчас, если бы в компании не было мастер-данных и шины данных. Про CRM вообще молчим!

image

image


Уровень 7: депрессия

Казалось бы, всё прекрасно. Обмены работают, данные ходят, бизнес-процессы выполняются. Но.

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

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

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

На следующий день вы заключили важный контракт. Предоплата? Нет, несколько дней деньги на счёт не поступают. Точно перечислили? Точно перечислили! А что не так? Звонок в банк, те говорят: ошибка! Оказалось, что в системе MDM устарели данные о реквизитах: они поменялись. А сотрудник, который должен был их исправить, заболел.

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

У вас даже возникли мысли, а не заменить ли используемые продукты. Вот, на одной презентации рассказывали, что продукты SAP (Oracle, IBM) не глючат! Разработчики возражают: нет, дело не в продуктах, дело в процессах. Провели внешний аудит, он подтвердил: технически системы работают корректно.

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

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

Проблема с качеством данных? Хорошо, у разработчиков, наверное, есть множество инструментов для контроля качества данных, для автоматизации процесса. Сколько-сколько? И что, только руками писать проверки?

К сожалению, простого решения у этой проблемы не нашлось. Её можно было бы проигнорировать на какое-то время, но в динамике стало понятно, что через пару уровней развития компании эта проблема вас просто похоронит. И никто конкретного не будет в этом виноват. Но как же тяжело внедрять сложные решения!

image


Уровень 8

Есть решение проблемы качества данных!

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

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

Шли долгие дискуссии на тему того, должна ли функция контроля качества данных быть централизованной или децентрализованной. Финансовый департамент считал, что качество данных по договорам и счетам их зона ответственности. Административно-хозяйственный считал своими данные по имуществу, и так далее. Быстро выяснилось, что с точки зрения разных мест в компании есть разные критерии по качеству данных.

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

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

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

Правил в системе было сначала 100, потом 500, через год уже около тысячи! Департамент HR здорово помог с тренингами, подсказал варианты мотивации сотрудников, сделали инфографику и мультяшный индикатор количества ошибок, отмечая их уменьшение. Началось даже соревнование, кто найдёт больше ошибок и добавит больше правил!

Следующий уровень развития системы DQS интеллектуальные правила, нечёткие правила, агрегирующие правила (например, итоговое значение в двух отчётах, описывающих одну и ту же сущность с разных сторон, должно совпасть). Высший уровень DQS контроль качества мастер-данных и даже их системное наполнение на основании государственных открытых данных. Пример сервисы по контрагентам на сайте налоговых, они позволяют контролировать правильность реквизитов в вашей MDM.

image

image


Уровень 9: принятие

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

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

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

Оставим за скобками административную часть и бизнес-процессы. Если говорить про интеграцию, технически сама задача не очень сложная. Проводится обучение новых сотрудников, затем фиксируется некоторая точка во времени, час Икс. После часа Икс все вновь запускаемые процессы, новые контрагенты, новые договоры должны вестись строго в ваших основных системах. Рост на 10-20%, даже на 50% эти системы выдержат без особых проблем. Все современные системы класса MDM, ESB, CRM и др. позволяют масштабировать себя, просто докупая новое серверное оборудование.

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

image

image


Уровень 10

Выгрузив в очередной раз отчётность из BI-системы, вы загляделись на цифры и задумались. Численность сотрудников в вашей компании скоро будет шестизначной, это население целого города. Годовой оборот близок к 0.1% ВВП России и превысил ВВП республик Алтай и Тува. На территории бывш. СССР рынок весь ваш! И, честно говоря, он занят полностью. На нём расти больше некуда.

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

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

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

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

И самое главное: данные должны храниться на серверах на территории Евросоюза. В дальнейшем эти или похожие требования будет появляться во всё новых и новых странах, а за их нарушение предусматриваются просто огромные штрафы. В случае Евросоюза это до 20 млн евро или до 4% от мирового оборота компании.

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

Местная компания, региональная, федеральная, что дальше? Глобальная?

Весь мир ждёт вас!

image

image


Итоги

Хочу поделиться несколькими выводами из рассказа выше. Не все выводы однозначные и предположу, что они могут вызвать возражения. Основное:

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

2. Важны не только сами мастер-данные, но и их качество. По мере роста вопрос качества данных выходит на первое место.

3. В то же время, каждый следующий уровень развития MDM, ESB, DQS дорог и влечёт за собой дополнительные расходы. Есть чёткая шкала, ориентируясь на которую, можно формировать текущую инфраструктуру. Создавать её с запасом больше, чем на 1-2 уровня не нужно.

4. Ответственность за качество данных должна нести не IT-служба, а сам бизнес. Задача IT предоставить удобные инструменты для реализации этой ответственности.

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

Приглашаю к дискуссии!
Подробнее..

Recovery mode Создаём компанию мечты управление качеством данных

27.04.2021 22:20:31 | Автор: admin
Самой дорогой ошибкой в истории, вызванной неправильными исходными данными, считается авария ракеты Ариан-5. Суммарный урон по итогу этого случая оценивают в 0.5 миллиардов долларов в ценах начала 1996 года.

Ещё одной, возможно, самой курьёзной, стала ошибка в огромном заказе от французских железных дорог SNCF на 2 тыс. поездов в 2014 году. Команда, которая формировала технические требования, собственноручно провела замеры габаритов перронов на нескольких десятках станций. Желая увеличить комфорт, они задали ширину составов впритык к максимальной. Измерения они проводили в окрестностях Парижа и о том, что в регионах на многих станциях перроны находятся ближе к путям, узнали уже при испытаниях. Цена ошибки модернизация всей инфраструктуры на сотни миллионов евро. Им бы там MDM с характеристиками станций

image

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

Эта статья продолжает статью "мастер-данные и интеграция" и более подробно освещает вопрос контроля качества данных, в первую очередь мастер-данных. Статья будет особенно интересна руководителям IT, архитекторам, интеграторам, а также всем, кто работает в достаточно крупных компаниях.

Содержание:


1. Словарь, виды бизнес-данных: мастер-данные, нормативно-справочная информация, операционные данные.
2. Коротенько о том, какие бывают ошибки.
3. Архитектура решений DQS.
4. Технические и нетехнические приёмы борьбы с ошибками:
4.1. НСИ.
4.2. Мастер-данные.
4.3. Операционка.
5. Что делать, когда ничего из перечисленного не помогло внедрять DQS.
6. И как делить ответственность?

Если терминология и проблематика вам уже знакомы, переходите сразу к части 3, про архитектуру DQS.

1. Словарь, виды бизнес-данных.



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

Многим уже набил оскомину пример того, как компании General Electric и Boeing создают цифровых дочек и зарабатывают на огромном объёме информации, собираемой от владельцев их техники самолётов, турбин, электростанций. Эти данные позволяют им повышать надёжность техники, предсказывать возможные отказы, сильно экономя на потенциальном ущербе, наконец, просто спасать жизни людей!

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

image
традиционная картинка про рост объёма данных почти всегда экспонента

По ходу деятельности особую важность для компании представляют собой три вида данных:

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

нормативно-справочная информация (НСИ) это понятие близко к мастер-данным, и во многих компаниях объединяется с ними. Разница в том, что эти данные существуют независимо от вашей компании: список (классификатор) стран мира, адресный классификатор, реестры банков, курсы валют;

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

Если НСИ можно сравнить с несущим скелетом, мастер-данные с венами и артериями, то операционка это кровь, которая бежит по этим венам.

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

image

2. Коротенько о том, какие бывают ошибки.



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


Основные виды ошибок, от которых страдает бизнес:

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

неполнота информации. Говорят, что полуправда хуже неправды, и в бизнесе это часто бывает критичным. Например, вы заключили крупный контракт с организацией и через некоторое время узнали, что в отношении руководства компании ведётся судопроизводство. Ваш контрагент может уклоняться от налогов или, чего хуже, заниматься противозаконной деятельностью. Через некоторое время с вами свяжутся конечно, ваш бизнес полностью легален, но кого обрадуют лишние проверки? А как хорошо было бы, если бы тогда, при нанесении контрагента в базу, ваша учётная система или CRM предупредила бы: внимание! Контрагент не прошёл проверку на благонадёжность!

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

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

3. Архитектура решений DQS.



DQM data quality management, управление качеством данных.
DQS data quality system, система [управления] качеством данных.


Перед тем, как рассказать непосредственно о системах управления качеством данных (DQS это не столько конкретное программное обеспечение, сколько подход к работе с данными), опишу IT-архитектуру.

Обычно, к тому моменту, когда возникает вопрос управления качеством данных, IT-ландшафт представляет собой следующее:

image
(схема из предыдущей статьи)

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

Традиционно на первом этапе DQS подключается к системе MDM, поскольку управление качеством мастер-данных считается более приоритетным, чем операционки. Однако, в дальнейшем она включается в общую шину данных как один из этапов процессов, либо представляет свои услуги в формате API. В конкретных цифрах между первой и второй схемой примерно десятикратная разница в объёме данных или один уровень по шкале из прошлой статьи.

4. Технические и нетехнические приёмы борьбы с ошибками.

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

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

4.1. Нормативно-справочная информация.

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

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

Пример #1. Наверняка вам для работы понадобится список стран мира. На него будут ссылаться многие другие справочники: контрагенты и клиенты (страна регистрации), валюты (курс какой страны), ваша география (в какой стране и по какому адресу расположен офис).

Значит, любая сущность, которая содержит в себе страну мира (даже если вы в ней выбираете из двух-трёх стран) должна ссылаться на этот справочник. А сам справочник должен заполняться строго на основании официальных классификаторов, в случае РФ это ОКСМ (общероссийский классификатор стран мира).

Если вы работаете на международном рынке, обратите внимание на нюанс: в разных странах разное представление о странах мира и их количестве. И речь не только про такие частично-признанные республики, как Абхазия или Южная Осетия. Например, около двадцати стран не признают существование Израиля и Китайской Народной Республики. Есть и точечные непризнания на территории СНГ, например, Армения не признаётся Пакистаном.

Страны мира (в РФ это и ниже ОКСМ), валюты (ОКВ), виды экономической деятельности (ОКВЭД), адреса (ФИАС), банки и их счета, клиенты и поставщики (ЕГРЮЛ и ЕГРИП) эта и множество другой информации публикуется государственными органами практически всех стран в виде открытых API и сервисов, и она должна загружаться только таким образом.


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

image

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

4.2. Мастер-данные.



Главная стратегия в отношении мастер-данных прозвучит, возможно, парадоксально: превращайте их в нормативку!

Пример #2. Справочник контрагентов юридических лиц и ИП, являющихся вашими клиентами или поставщиками (в компаниях уровня выше 5-6 часто одновременно и тем, и тем).

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

Это не значит, что вы должны занести в свой справочник контрагентов все несколько миллионов записей из открытых данных. Но новые записи должны добавляться как раз на их основании. Базовые реквизиты можно взять с сайта налоговой. Если вас интересуют данные бухгалтерской отчётности или среднесписочной численности (например, в целях аналитики, развивать отношения с наиболее крупными клиентами) берите их у Росстата (ссылка). Если у вас есть процедура проверки на благонадёжность берите данные с сайтов соотв. служб с помощью своей ИТ-команды, либо есть вариант покупать уже подготовленные и выверенные данные у провайдеров (например, СПАРК-Интерфакс). Цена вопроса, сотни тысяч рублей в год, при ваших масштабах окупается за несколько месяцев.

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


Пример #3. Физические лица, сотрудники вашей компании. Ошибки в паспортных данных, неправильные ФИО и дата рождения, СНИЛС. Сокрытая информация о судимости, просроченной задолженности перед госорганами, алиментах.

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

Естественным продолжением этой истории будет электронный кадровый документооборот электронная трудовая книжка, электронные больничные и др., что значительно сэкономит трудозатраты у кадровиков. В пределе это позволит одному кадровику обслуживать не 200-300 сотрудников, а 1000+.

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

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


4.3. Операционка.



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

Пример #4. Хорошо, скажете вы, контрагенты и физлица это просто. Но что делать с более бизнес-специфичными процессами и данными? Искать государственные классификаторы и другие гарантированные источники этой информации.

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

Создаём справочник автомобилей это мастер-данные. Модель автомобиля, его нормы расхода топлива и характеристики выбираем из гос. классификатора моделей (не забывайте настроить регулярную интеграцию, чтобы данные не устаревали!)
Информацию о конкретном автомобиле заполняем строго по госномеру на основании подключаемого справочника (например, Автокод).

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


Пример #5. Командировки сотрудников: билеты, гостиницы и прочие расходы.

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


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

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

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

image
www.europeandataportal.eu/en

Где же здесь DQS, спросит внимательный читатель?

А про неё ещё ничего и не было :)
Всё вышеперечисленное это, по сути, стандартные инструменты и методы для организации бизнес-процессов с минимальным количеством ошибок.

5. Что делать, когда ничего из перечисленного не помогло внедрять DQS.



Сунь-цзы учит, что лучшая битва та, которую удалось избежать.

Ситуация с внедрением DQS чем-то похожа.

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

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

На каком уровне развития компании нужно вводить DQS? Как процесс DQM на 4-5 (раньше MDM-системы!), как организационно выделенную функцию на 7-8.

5.1. DQM как процесс.



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

Ваша задача на данном этапе будет заключаться в выстраивании процесса DQM. Он следующий:

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

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

Наибольшие затруднения в таком случае возникают с придумыванием новых правил.

5.2. Правила.



Если для такой сущности, как ФИО, ваша фантазия ограничивается обязательностью фамилии и имени, а для даты проверкой на не больше ста лет, не расстраивайтесь!

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

По сути, это пошаговый скрипт, у которого на входе определение ваших данных, а на выходе набор правил на все случаи жизни. Методика, известная под названием таксономия грязных данных, была разработана группой европейских data-scientistов в начале XXI века.

Суть подхода, а также практические примеры приведены в их системной статье, к счастью, уже опубликованной в переводе здесь, на Хабре habr.com/ru/post/548164

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

Пример #6. Строгая типизация. Если в справочнике используется тип данных дата, то структура даты должна быть максимально явной. Если вы решили сэкономить две секунды для операторов, и сделали шаблон вида __.__.__ с подсказкой день, месяц, год, будьте уверены, что в первый же день появятся записи 18.04.21, 21.04.18 и 04.18.21.


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

Пример #7. Запрещённые символы в максимально широком списке полей, словарные проверки. Например, если речь идёт про образование (должность), и классификаторы специальностей не помогли, вы позволяете пользователю ввести данные в текстовом поле, пусть там будут запрещены точки, кавычки, отдельно стоящие чёрточки (список не полный). Пример информации, качество которой повышается: доктор технических наук, д.т.н., ДТН, д-р техн. наук и т.д.


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

Кстати, про ФИО, и особенно про отчество. Если вы предполагаете работу с физическими лицами из стран Средней Азии или Ближнего Востока, кейсы с ибн, бен, кызы, оглы (и др.) могут стать критичными в вопросах качества данных, например, при поиске дубликатов. Аналогичная история с порядком употребления этих данных (Джон Смит, Смит, Джон) и с двойными именами (Анна Мария, Анна-Мария, Джон Чарьлз Смит). Также для многих не иметь фамилию это нормально. А ещё, с точки зрения одних, Наталья и Наталия разные имена, а с точки зрения других одинаковые. А ещё есть сэр, доктор

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


6. Кто несёт ответственность за DQS?



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

Вопрос про ответственность за процесс DQM, на самом деле, даже более общий: кто несёт ответственность за качество данных в компании? Традиционно бизнес-пользователи и IT-департамент в ответе на этот вопрос выступают антагонистами.

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

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

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

Восхитительнейший пример и мотивацией и даже визуализацией последствий ошибок приведён в статье habr.com/ru/post/347838 в этом примере ответственным за процесс DQM выступает служба IT с развитыми компетенциями бизнес-анализа. Причём сами по себе компетенции в DQM не сложны, и могут быть развиты у любого аналитика за пару месяцев.

Ещё один пример, интересный тем, что в процесс DQM включено также управление качеством бизнес-процессов, приведён в статье habr.com/ru/company/otus/blog/526174.

Итоги



Общие выводы из этой статьи парадоксальны.

Если в вашей компании был задан вопрос кто несёт ответственность за качество данных, то вы попали в ловушку. На него нет правильного ответа, т.к. сам вопрос неправильный. Если вы попробуете сходить по этому пути, со временем поймёте, что единственный подходящий ответ на этот вопрос (все) ничего не даст вам на практике.

Правильный подход разделение вопроса на два блока.

Первый выстраивание DQM как процесса, внедрение DQS, формирование правил (не на разовой основе, а как постоянно идущий процесс). Этот блок живёт там, где сильны функции анализа, обычно, в IT, но необязательно.

Второй блок сам ввод первичных данных это место, где принимаются решения о конкретных данных, но не наобум, а на основании всех правил. Таким образом, внедрение DQS важный шаг в сторону data driven company.

Приглашаю к дискуссии!
Подробнее..

Recovery mode Создаём компанию мечты нет хайпу

01.06.2021 00:14:15 | Автор: admin
Наверняка в вашей компании уже не раз появлялись ребята в дорогих костюмах и с хорошо подвешенным языком, увлекательно рассказывающие, что без современных айти-штучек компания не проживет и несколько лет!

Все эти data lake (болото данных), КХД (корпоративное кладбище данных), data mining (смотри, не подорвись), data governance (стань рабом своих данных) и им подобные не исчезают из их рассказов, периодически сменяя друг друга. Срок жизни очередного хайпа редко превышает год-два, но при желании для вас с большим удовольствием откопают любую почти забытую технологию.

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

В этой статье я постараюсь рассказать о старых-добрых технологиях, которые всё ещё работают. О том, что можно извлечь из перечисленных выше хайповых технологий и как всем этим пользоваться простым смертным, типа нас, не нанимая толпу дата-сайентологов с зарплатами >10 тысяч $ в месяц.

image


Статья продолжает цикл:
Создаём компанию мечты: мастер-данные и интеграция
Создаём компанию мечты: управление качеством данных

Содержание


1. Big data: постановка проблемы
2. Мастер-данные: бессмертная классика
3. Как хранить данные: нужны ли КХД
4. Нормализация, или зачем вам болота данных
5. Почему дата-сайентист получает больше аналитика, а делает меньше?
6. Шина данных vs микросервисы
7. Как вообще не попасть на хайп?

1. Big data: постановка проблемы


Роль big data в развитии современной цивилизации впечатляющая. Но не по той причине, которая вам кажется.

Если интернет в каждой деревне и каждом телефоне появился благодаря порно и соцсетям (мессенджерам), то big data подарила триллионы долларов производителям жёстких дисков и оперативной памяти.

Проблема в том, что реальная польза от современной big data (в широком смысле слова) для всего человечества близка к пользе от порнографии, т.е. за несколькими исключениями нулевая!

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

Проблема, если быть точнее, в повторяемости результатов. Скажу по секрету, что скамейка запасных у продажников big data короткая. Если вы попросите их привести ещё несколько примеров, список закончится на втором десятке. Уверен, что мессенджеров и порносайтов они смогут назвать куда больше :) потому что их просто физически больше.

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

А General Electric сформировала своё конкурентное преимущество основываясь на методах математического анализа и статистики, которые можно найти в любом курсе математики для университета. Понятия big data тогда ещё не было.

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

Что же делать? Работать! Долго, скучно и уныло, стараясь создать такую атмосферу, которая поощряла бы активное думание. Как в канонических примерах от Bell Labs или той же GE. Это вполне возможно, более того, на это способны самые обычные люди, как вы и я, если их нужным образом замотивировать.

А начать нужно с

2. Мастер-данные: бессмертная классика


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

В среде дата-сайентистов младше 30 лет встречается убеждение, что окно для внедрения систем MDM началось примерно в 2008 и закончилось в районе 2012-15 годов. Что после этого появилось так много новых инструментов (всякие hadoop и spark), что заморачиваться с мастер-данными уже не нужно, не нужно ходить и договариваться с владельцами всех систем, думать о последствиях выбора архитектуры MDM и каждого конкретного реквизита в каждом справочнике.

К сожалению для них и к счастью для вас, это окно не закрылось. MDM-системы всё так же актуальны, как и системы бухучета или взаимодействия с клиентами. И думать и договариваться всё ещё нужно.

3. Как хранить данные: нужны ли КХД


Нет, корпоративные кладбища данных вам не нужны.

Идея, что для целей аналитики нужно иметь специальным образом подготовленные наборы всех данных (идеологи КХД не только выделяют это слово жирным, но и подчёркивают его двойной чертой) в вашей компании, абсурда. Коэффициент реального использования этих данных минимальный, 99% из них не используются никогда.

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

4. Нормализация, или зачем вам болота данных


Это раздел про data lake, или болото данных. Легенды гласят, что можно сваливать все данные без разбору в одну большую кучу. Не нужно приводить все данные к одному формату, не нужно нормализовать и вычищать их!

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

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

И главный вопрос как какие-то жулики сумели убедить хоть кого-то в работоспособности этого подхода. Я склоняюсь к гипнозу :)

5. Почему дата-сайентист получает больше аналитика, а делает меньше?


Маркетинг, грамотная самопрезентация, максимум уверенности в себе. Не исключаю также гипноз :)

6. Шина данных vs микросервисы


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

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

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

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

Уже на десяти системах прекрасно выглядевшая на старте архитектура, подход превращается в некий такой клубок, паутину, когда определённые потоки отваливаются и не работают месяцами.

image

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

7. Как вообще не попасть на хайп?


Вы познакомились с несколькими примерами хайпа, когда какой-то подход или технология могут оказаться бесполезными. И это с учётом того, что, по мировой статистике, доля успешно выполненных проектов по разработке и внедрению в IT редко превышает 40%.

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

Чтобы не попасть на хайп, перед очередным внедрением нужно выяснить следующее:

у технологии есть большая скамейка запасных. Количество приводимых примеров успешного применения должно превышать пару десятков, и от них не должно возникать ощущения, что тут происходит какая-то магия;
технология должна проходить тест на бабушку (объяснение сути должны быть настолько понятным, что его осилит даже ваша бабушка повторю, никакой магии);
у технологии должен быть конкретный, оцифрованный список ачивок, которые в результате получит ваша компания. Внедренцы MDM, CRM или той же 1С-бухгалтерии могут часами рассказывать о пользе их решения на примере ваших конкретных задач. Внедренцы Big data вообще начинают рассказывать, что сначала соберём кучу данных, а потом посмотрим, что с ней делать;
и, наконец, технология должна быть фальсифицируемой (в смысле критерия Поппера), т.е. внедренец должен чётко понимать область её применения и актуальности и суметь привести доводы против (!) внедрения. Не нужно забивать гвозди микроскопом, и вообще, например, если у вас мало клиентов, нужна ли вам супер-пупер CRM?

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

Можете предложить ещё какие-нибудь критерии?
Приглашаю к обсуждению!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru