Принципы (паттерны) работы аналитика с данными

Меня зовут Мария Петрусенко. Я независимый аналитик данных. Работаю в анализе и учете больше 10 лет. Более детально и углубленно в анализе – последние 5 лет. Занимаюсь средними или крупными проектами. Чаще всего работаю в холдингах.

Хочу обсудить принципы, которые могут повысить качество работы аналитика с данными.

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

Сегодня мы:

• рассмотрим принципы, которыми можно руководствоваться в ежедневной аналитической работе;

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

• посмотрим влияние глубины анализа на ход исполнения задачи;

• разберем критическое мышление и способы, как улучшить этот навык;

• посмотрим сквозной пример, как использовать все это вместе: общие принципы, словарь терминов, глубину анализа и критическое мышление при работе над задачей или проектом;

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

Общие принципы работы, которыми следует руководствоваться аналитику данных

Начнем с разбора принципов работы аналитика с данными.

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

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

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

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

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

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

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

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

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

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

Глоссарий, вокабуляр. Как приводить понятийный аппарат к единому знаменателю

Следующее, о чем я хочу поговорить – это понятийный аппарат.

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

Чтобы избежать недопонимания:

• Уточняйте значение терминов у собеседника: спросите, что именно он имеет в виду под тем или иным словом.

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

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

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

«Analyze it!». Глубина анализа и последствия погружения в недра данных

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

Для небольших задач:

• Важно максимально четко описывать потенциальные риски, возникающие из-за ограниченного анализа и недообследованности задачи.

• Можно прямо в задаче указать, что именно было проанализировано, а что – нет.

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

Для крупных задач и проектов:

• Необходимо уделять значительное время анализу:

  • пообщаться со всеми затронутыми в проекте рабочими группами;

  • описать схемы бизнес-процессов;

  • согласовать стыки учетных модулей;

  • построить методы и модели;

  • проработать аналитические отчеты.

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

Критическое мышление и технология его развития

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

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

• Вы собираете данные от заказчика, коллег или других заинтересованных сторон.

• Проверяете их достоверность, сопоставляя с надежными источниками, на цитаты из которых вы можете ссылаться.

• Анализируете разные точки зрения, учитывая контекст и возможные альтернативы – имеет смысл рассмотреть мнение ваших коллег и различных сотрудников заказчика.

• На основе этого делаете выводы и формулируете рекомендации.

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

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

• Развивайте внимание.

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

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

• Читайте сложную литературу.

  • Выбирайте книги, которые заставляют задуматься.

  • Если встречаете непонятные слова или идеи, выписывайте их и разбирайтесь в значении

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

• Слушайте сложную музыку.

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

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

• Тренируйте ум.

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

  • Играйте в шахматы, логические игры, решайте головоломки.

• Осваивайте новое.

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

  • Изучайте языки и не только филологические. Это могут быть языки программирования, кулинарный язык, язык живописи и пр.

• Вдумывайтесь.

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

От теории к практике. Как это работает: сквозной пример работы аналитика со сложным заказчиком

Рассмотрим все, что озвучено выше, на сквозном примере.

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

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

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

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

• Вы понимаете, что вы дипломированный специалист.

• У вас есть успешно реализованные проекты по автоматизации систем.

• Вы умеете анализировать информацию, опираясь на практический опыт, деловые стандарты и учетные методики.

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

Как воспринимать слова заказчика?

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

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

Посмотрим пример работы принципов, как это работает.

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

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

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

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

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

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

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

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

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

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

• разницы могут быть только по ПБУ 18;

• требуется восстановление учетных операций;

• требуется улучшение качества ведения учета;

• на данном этапе внедрение каких-либо доработок не требуется.

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

Т.е. аналитик:

• получил информацию;

• обработал ее – сопоставил с тем, что он знает;

• пришел к аргументированным выводам;

• вынес итоговое умозаключение и выдал свои рекомендации.

Что может произойти? Финансовый директор может возразить, что у него нет времени на долгоиграющие процессы, связанные с восстановлением учета и повышением качества данных. В этом случае вы можете предложить провести исследование и на конкретных примерах проанализировать, почему не закрываются счета 20, 25, 26. Это позволит выявить проблемные зоны, мешающие автоматизированному закрытию месяца, объяснить причины их возникновения и определить, над чем стоит поработать.

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

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

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

Что делать, если…? Горячая подборка проблемных ситуаций в работе аналитика

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

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

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

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

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

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

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

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

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

Важно помнить, что ответственность за выполнение задачи лежит на обоих специалистах:

• Аналитик отвечает за корректный выбор объектов метаданных и их настройку в пользовательском режиме.

• Разработчик – за качество написанного кода и его соответствие техническому заданию.

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

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

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

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

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

Источники при создании доклада

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

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

Также рекомендую материалы Татьяны Владимировны Черниговской – ее интервью, где она рассказывает о мысли, сознании, мышлении и различных процессах головного мозга. Она также является фанатом произведения «Алисы в стране чудес» и очень много приводит интересных цитат из него. Интересно ее слушать.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.