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


На этот раз задача оказалась предельно простая и прагматичная, но ее решение дает далеко идущие последствия.


Кейс


Суть задачи в следующем:


  1. Есть длительные контракты на оказание услуг.
  2. По этим контрактам должна осуществляться отчетная деятельность в виде большого количества бумажных документов (коробки), прошитых и под синей печатью. И никак иначе.
  3. Отчетность ежемесячная.
  4. Отчеты сами по себе достаточно формализованы, но для их подготовки требуется длительная и, как уверенно декларовали исполнители, строго ручная работа по сбору информации из десятка систем, сопоставлению и сверке, анализу, выработке агрегатов и формированию word документов в согласованном виде.

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


Один из примерных видов отчета выглядит следующим образом:
image
Совокупное количество страниц исчисляется тысячами (десятками тысяч в неудачный месяц).


В качестве источников данных выступают пара сервис десков, тройка систем мониторинга, корпоративные справочники, договора, учетная система.


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


  • 80% времени на формализацию (что надо делать в любом случае, будь то ручной или автоматический сбор данных);
  • 20% на воплощение этих процедур в коде на R.

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


Вызов был принят.


Через 4 часа мы уже имели рабочий R скрипт (~4 экрана с учетом комментариев), который исполняет эту задачу по подготовке одного из отчетов.
Скрипт исполняет работу под ключ, выдавая на выходе word файл требуемого формата с актуальными данными:


  1. загружает данные из трех источников (excel и 2 базы);
  2. проводит предобработку по идентификации подтвержденных кейсов;
  3. проводит расчеты (весьма простенькие, но это роли не играет) по соотнесению кейсов с контрактными SLA;
  4. проводит очистку и консолидацию временных интервалов;
  5. проводит расчет месячных показателей;
  6. формирует word файл, содержащий заголовки, текст, сгенерированные форматированные таблицы, сгенерированные по данным графики.

Существенным дополнением к предыдущим публикациям является последний пункт — генерация word файла. Эта задача элегантно решается с помощью кросплатформенного пакета ReporteRs. Кроме создания word файлов он также позволяет генерировать powerpoint файлы, что также весьма полезно. Не секрет, что во многих компаниях любят смотреть отчетность в виде презентаций. Хороший мануал с примерами можно почитать здесь: «Create and format Word documents using R software and Reporters package».


В итоге, 2 чел * 2 недели = 1 чел мес. заменяется на работу скрипта в течение 5-15 минут. Выгода для компании очевидна.


Заключение


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


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


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


P.S.
Использование подобного подхода позволяет в пару-тройку строчек проделывать такие трюки, которые весьма трудозатратны при ручном создании word отчета:


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

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


Предыдущий пост: «Еще примеры использования R для решения практических бизнес-задач»

Поделиться с друзьями
-->

Комментарии (22)


  1. AristarXXXX
    08.12.2016 12:23

    Продолжаем двигать R в массы! :)
    Ставьте лайки, подписывайтесь на наш канал.


    Кроме шуток. Подход оказался неожиданно простой. Сделать всё, что мы и так делаем, а потом перелопатить это в олдскульный вордовский документ.
    Кстати, пакет ReporteRs оказался столь могучим, что может даже взять за осову документа не пустую страницу, а файл-шаблон. Т.е. всякие корпоративные шапочки и т.д.
    Область применения может быть самая нестандартная. От вышеописанных отчётов к контрактам, до шаблонов заявления на отпуск. Плохо что ли? Человек залогинился куда-то, считались его данные, вбил даты отпуска, а ему готовый документ сформировался. И это не какой-то космос и высшая математика. Это несколько бесхитростных строчек в коде и общее понимание процесса.
    Комментаторам в стиле "А что у вас до сих пор текстовые документы гуляют в организации?" предлагаю сразу обращаться в лигу сексуальных реформ. Да, гуляют и ещё крайне долго будут гулять :)


  1. ikbrain
    08.12.2016 12:49

    Активно агитирую знакомых всех возможных профессий поковырять R, активно помогаю немногим неиспугавшимся. Мне кажется, в 2016 года каждый, кто значительную часть работы выполняет на компе, должен если не знать, то хотя бы представлять себе какой-нибудь простой скриптовый язык. Хотя бы потому что после определённого уровня (относительно небольшого) многие ежедневные дела так и начинают кричать тебе: «Автоматизируй меня! Автоматизируй меня!» Ну прада, вот есть у тебя 4 десятка папок, из каждой надо взять файл с одним и тем же шаблоном названия, а они это делают руками. Я прямо физический дискомфорт от этого испытываю.

    Учите R.


    1. knagaev
      08.12.2016 13:13

      Я подписываюсь под вашими словами.
      Только одна небольшая ремарка: R всё-таки не «какой-нибудь простой скриптовый язык».
      Он требует очень серьёзного изучения и принятия его синтаксической парадигмы.
      И иногда даже несколько другой парадигмы для хороших пакетов (tidyverse).

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


      1. ikbrain
        08.12.2016 13:18

        Под «простым» я понимаю порог вхождения. Это не С++ и даже не Питон.


        1. knagaev
          08.12.2016 15:32
          +1

          Питон проще :)
          Здесь (в R) очень много функциональщины в хорошем смысле этого слова.
          Питон — язык, изначально разрабатываемый для удобства, в нём приятно именно писать скрипты.
          А в R всё-таки достаточно осталось из его научного прошлого — у учёных немного другой взгляд даже на именование стандартных вещей в программировании.
          Если бы не Hadley Wickham, в R по-прежнему было бы «странно» работать программистам, пришедшим с других языков.


          1. ikbrain
            08.12.2016 15:36

            Мне кажется, зависит от опыта. Я вот начинал с R, поэтому работа с данными в Питоне (читай: pandas) кажется мне не такой удобной. Я ковыряю сейчас Питон, хотя бы потому что полезно знать несколько инструментов, но для данных всё-таки R и Cpp пока.


  1. knagaev
    08.12.2016 13:09

    Бойтесь луддитов! История повторяется по спирали :)


  1. iSergios
    08.12.2016 15:05
    +2

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


    Вообще не очевидно. В смысле все очень сильно зависит от руководства. Лет 8 назад, придя на новую работу (с IT, правда, связанную слабо), получил в число своих обязанностей подготовку и составление ежемесячных отчетов (порядка 7-8) по подконтрольным, скажем так, организациям. Ушедшая на повышение коллега убивала на них порядка 2-3 недель в месяц, делая, естественно, все вручную. По сути на этом месте занимались вот этими отчетами и иногда другой работой. На автоматизацию ушло 3 месяца, из которых 2 дня — на написание скриптов и остальное время — на стандартизацию представляемых нам отчетов. Через три месяца процесс сбора и обработки всех данных занимал минут 15, включая выгрузку всего этого хлама с электронной почты. Так вот, к отчетам, созданным «компьютером» руководство отнеслось крайне скептически и (несмотря на то, что скрипты проверяли все, что только можно, и ошибки-пропуски были сведены на нет) попросило меня уделить этому больше внимания (т.е. делать вручную). Итог был прекрасен — я долгое время делал отчеты 15 минут в месяц, а остальное время занимался своими делами, чем вызывал наидичайший баттхерт у коллег. При сдаче, правда, обязательно говорил, что все проверил лично, с калькулятором, да.


    1. PaulIsh
      08.12.2016 15:43
      +1

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


    1. i_shutov
      08.12.2016 15:55

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


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


  1. Anton_Barhan
    08.12.2016 19:57

    Коллеги, а вот чтобы почитать-посмотреть, чтобы это освоить. У меня каждый месяц отчеты по отделу, и я, блин, фигачу его руками(((


    1. iLeg0
      08.12.2016 21:43

      Порекомендую Python (в освоении прост, куча библиотек под все случаи жизни, просто пишутся любые парсеры, аналитические скрипты и т.д.). Коллеги выше советовали R, комментировать не стану — не пробовал.
      С позволения администрации, выложу парочку ссылок:
      — бесплатный онлайн самоучитель — http://pythontutor.ru/
      — библиотеки — https://github.com/vinta/awesome-python
      — очень крутая либа для работы с Экселем в лайв режиме — https://www.xlwings.org/


      1. i_shutov
        09.12.2016 10:08

        а за ссылки большое спасибо. в части стыковки Python <-> Excel оставался на pywin32 и COM модели.



    1. knagaev
      09.12.2016 09:28

      В комментариях к статье про R всё-так рискну предложить ресурс R :)
      RStudio Online learning


    1. i_shutov
      09.12.2016 09:46

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


      Там же написано, почему R, а не Python. По совокупности возможностей. Python — прекрасный язык, но 10 лет попыток прикрутить его для полноценной работы с данными каждый раз натыкались на массовое применение изоленты. А еще дилемма Python 2 или 3. Она вроде бы как закончилась недавно, но для меня это уже слишком поздно, поскольку я нашел ответы на все возникающие вопросы в рамках экосистемы R.


  1. aqvalite
    08.12.2016 21:33

    1. Так а где код? Интресно все же решение посомтреть вживую
    2. Есть ли такой пакет ReporteRs для Python?


    1. AristarXXXX
      09.12.2016 11:11

      Отвечу в обратном порядке.


      1. По поводу Python не скажу.
      2. По поводу кода — загрузка данных и вычисления SLA слишком специфичны и индивидуальны, чтобы тут приводить. А формирование самого файла ниже (полная форма закомменчена, а сокращённая через пайпы внизу)

      Кусок кода для формирования word документа
      ################################################################## Формируем шапку документа
      # # Создаём болванчик ворд документа
      # doc <- docx()
      # # Название документа. Жирненькое, сдвинутое в центр.
      # doc <- addParagraph(doc,
      #                     pot(doc_title, format = textBold()),
      #                     par.properties = parProperties(text.align = 'center'))
      # 
      # # Добавляем параграф с текстом про даты, затем со статичным текстом
      # doc <- addParagraph(doc, dates_text)
      # doc <- addParagraph(doc, my_text)
      # 
      # 
      # # Добавляем содержание
      # doc <- addTitle(doc, "Содержание")
      # doc <- addTOC(doc)
      # doc <- addPageBreak(doc) # Перенос на следующую страницу
      # 
      # 
      # ######################################### Первый блок данных
      # # делаем заголовок первого уровня
      # doc <- addTitle(doc, value = "Устранение ТТ")
      # 
      # 
      # ######################################### Формируем таблицу
      # doc <- addFlexTable(doc, MyFTable)
      # 
      # ########################################### Итого для таблицы ##########################
      # doc <- addParagraph(doc, pot(total_text, format = textBold()))
      # doc <- addPageBreak(doc) # Разрыв страницы
      # 
      # 
      # ########################################## Второй блок данных
      # # делаем заголовок первого уровня
      # doc <- addTitle(doc, value = "Проведённые плановые работы")
      
      ########################### Сокращённая форма записи
      doc <- docx() %>%
        addParagraph(pot(doc_title, format = textBold()),
                     par.properties = parProperties(text.align = 'center')) %>%
        addParagraph(dates_text) %>%
        addParagraph(my_text) %>%
        addTitle("Содержание") %>%
        addTOC() %>%
        addPageBreak() %>%
        addTitle("Устранение ТТ") %>%
        addFlexTable(MyFTable) %>%
        addParagraph(pot(total_text, format = textBold())) %>%
        addPageBreak() %>%
        addTitle("Проведённые плановые работы")


  1. 13i
    08.12.2016 23:13

    А как часто бывают случаи SLA, отличные от высокого?


    1. i_shutov
      08.12.2016 23:22

      Не совсем понятен вопрос. Если про правила расчета, то там месячный sla с различными пороговыми значениями, а композитная величина потом преобразуется в штрафной коэффициент.


    1. i_shutov
      09.12.2016 09:50

      прошу прощения, упустил картинку. Там указан SLA по тикету, а есть еще композитный SLA по услугам, включенным в рамочный контракт. По тикетам случаи бывают, но, как обычно миллион гибких уровней трансформируется в 3: "все бросили и побежали", "покурю и начну заниматься", "посмотрим завтра".


    1. AristarXXXX
      09.12.2016 10:46

      Отвечу, как всё у нас.
      SLA подразумевает просто время устранения. В данном контракте особенность предмета контракта, что там почти весь SLA "Высокий".
      Но сути это особенно не меняет. Берётся время начала работы, время окончания, вычитаются какие-то задержки со стороны Заказчика (если они имеются), сравнивается со значением SLA (вошло не вошло).
      За кадром остался момент итогового отчёта. Помимо SLA каждого отдельного тикета — есть ещё общий SLA, который прописан, как "Общее время, на которое суммарно просрочены все тикеты". Оно для разных уровней SLA тоже разное. Но оно тоже считается не сложно. Потом в итоговый отчёт идёт помимо таблицы, что на скриншоте в статье, общая таблица.
      Если есть более конкретные вопросы — пишите. Попробуем посмотреть на досуге.