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

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

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

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

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

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

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

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