Как пасти желтых котов. Практика разделения оперативного и финансового учета для увеличения выработки сотрудников

Публикация № 1470366 09.07.21

Методология - Управление командой - Учет рабочего времени

С проблемой учета работ сотрудников сталкиваются все компании, оказывающие услуги по разработке, внедрению и поддержке программных продуктов. О том, как увеличить выработку сотрудников путем выявления скрытых трудозатрат и перераспределения нагрузки в команде, рассказал директор и ведущий разработчик компании «Арт Порт» Максим Артеменко.

О нашей компании

 

 

Я руковожу компанией «Арт Порт», которая входит в группу компаний «Арт Софт». Нашей группе компаний уже более 25 лет, мы разрабатываем отраслевые решения для портов, зерновых терминалов, элеваторов и т.д. – в основном занимаемся транспортной и портовой логистикой.

Я сам в 1C с 2012 года – сначала был просто разработчиком, потом стал руководителем разработки, т.е. вырос из разработчика в руководителя проекта.

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

  • Во-первых, мы зависим сами от себя, поскольку 80% нашей работы – это разработка/ продажа/ внедрение наших собственных отраслевых решений.

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

 

Проблемы учета работ сотрудников

 

 

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

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

Так вот, три года назад, когда я только начал непосредственно руководить разработчиками, а не быть в их числе, мы в компании для собственного учета использовали программу УНФ – она использовалась для ведения взаиморасчётов с клиентами/ выставления счетов и т.д.

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

В целом, был бардак:

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

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

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

  • Одно «Задание на работу» не всегда соответствовало одной задаче, при этом расшифровка счета, который выставляется клиенту, всегда детализировалась по задачам, т.е. одно «Задание на работу» соответствовало одной строчке расшифровки счета. Но поскольку сотрудники вносят описание задачи для клиента сразу напрямую, то возникает проблема – что делать, если у одной задачи несколько исполнителей? Например, в спецификации прописано: «Разработка подсистемы взаимодействия с весами» – одна задача на 50 часов. И хотя ей по факту будут заниматься: администратор, который найдет драйверы для весов, 1С-разработчик, тестировщик, консультант, сервис-инженер и т.д., но клиенту все эти действия не выставляются как отдельные строчки – ему выставляется как одна строка. Таким образом нам было нужно иметь возможность указывать на одну задачу несколько исполнителей.

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

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

 

Требования к системе учета задач

 

 

Когда мы проанализировали проблемы учета времени, мы сделали выводы, что:

  • Факт времени должен идти отдельно от финансов. Т.е. я как руководитель хочу понимать, каким видом деятельности занимался мой сотрудник в течение дня. Например, сотрудник выставил себе за определенную работу 30 часов, но я предполагал, что эта работа займет не более 20 часов. Возникает вопрос – это я как руководитель неправильно оценил задачу? Или я оценил правильно, но задача из-за каких-то факторов заняла больше времени? Или сотрудник долго сдавал работу заказчику? В чем проблема, почему задача так долго выполнялась? Но при этом даже если факт времени превысил количество часов, которое мы можем выставить клиенту, это не обозначает, что эти часы нужно выставлять. Чаще всего это уже какая-то наша проблема, мы не учли какие-то моменты. И тогда это, действительно, уже будет наш убыток.

  • Алексей Лустин из компании «Серебряная пуля» любит говорить, что «Все есть код». А мне нравится связанное с этим утверждение, что «Все есть задача». Раньше мы УНФ учитывали только те задачи, которые делались для нашей фирмы или для клиента – например, разработка нашего отраслевого решения или его тестирование, а по платным работам для клиента писали в трудозатраты по времени только то, что выставится клиенту. В такой ситуации непонятно, куда уходит время – это нигде не регистрируется. Поэтому приняли решение, что на все нужно создавать задачу, нет задачи – нет работы. В идеале каждая минута должна быть расписана – чем ты занимался. Поначалу это сложно, но потом это приносит реальную пользу.

  • Нужна отдельная система оперативного учета. В 50% случаев на проектах CRM-блок или подсистему управления производства выделяют отдельно от бухгалтерской системы. Мы тоже решили, что нам для учета задач нужна отдельная система, которая изначально не будет связана с финансовым учетом. Задачи на этапе планирования не должны детализироваться на тестирование/ документирование/ постановку задач бизнес-аналитику, не должны быть связаны с «Заданиями на работу» и взаиморасчетами с клиентами.

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

 

 

К системе учета задач мы сформировали следующие требования:

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

  • Для разработчиков в задачах нужна возможность указывать специфические данные и статусы. У нас разработчики и линия консультации вели свои задачи в одной системе, при этом у линии консультации с задачами все было просто – там просто статусы «На рассмотрении», «В работе» и «Закрыто». А у разработчиков достаточно много специфических этапов: «Тестирование», «Code review» и т.д. Помимо этого, в задаче нужна возможность указывать такие параметры, как конфигурация, параметры подключения, VPN и т.д. – множество настроек.

  • У клиента должен быть доступ к просмотру статусов и постановке задач в бэклог, он должен иметь возможность анализировать, кто и чем занимается. Это нужно, чтобы клиент не сам у нас спрашивал, как дела, а мог сам в любой момент зайти и посмотреть на бэклог (только на то, что ему доступно – без детализации по задачам). На YouTube есть вебинар Алексея Лустина о том, что клиентов не нужно пускать в вашу Jira (в ваш тасктрекер), а нужно пускать в ваш Confluence, т.е. нужно некое общее пространство, в котором вы сможете оперативно осведомлять заказчика о проекте.

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

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

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

 

Поиск решения

 

 

В процессе поиска решения я проанализировал порядка десяти разных продуктов – Итилиум (Service Desk), JIRA, Redmine, ЭСТИ и т.д., но не нашел ни одного, которое бы полностью покрывало все наши требования.

Некоторое время мы активно пользовались Битрикс24 и Trello.

Плюсы Битрикс24:

  • не требует затрат на внедрение;

  • может быть быстро внедрен прямо сейчас;

  • можно везти заказы;

  • есть CRM-блок;

  • можно вести задачи проекта совместно с клиентом – он может видеть статус ваших задач.

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

Также мы попытались использовать для трекинга задач Trello, но столкнулись с тем, что там нет разделения, что показывать клиенту, а что не показывать. К тому что, что касается интеграции, в Trello есть возможность выгрузки задач в JSON, но нам по ряду причин результаты интеграции с 1С через JSON не понравились.

 

 

Выводы, которые я сделал в результате поисков системы для учета задач, можно охарактеризовать фразой: Eat your own dog food – разработчики должны использовать то, что они сами продают и внедряют.

 

Управление задачами

 

 

В результате на просторах Инфостарта я наткнулся на очень хорошую бесплатную разработку Антона Иванова «Управление задачами», которая достаточно активно сопровождается автором – он развивает свой продукт через GitHub, а для общения с пользователями использует Telegram-канал https://t.me/mtasks.

На основе этого решения мы сделали свою собственную отдельную систему «Управление разработкой» и настроили для нее обмен с нашей финансовой системой.

 

Алгоритм работы с задачей

 

 

Опишу используемый у нас алгоритм работы с задачами:

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

  • Далее задача начинает перемещаться по заранее определенным статусам – «Идея к обсуждению», «Зарегистрирована», «Бэклог», «К выполнению» и т.д. При перемещении задачи в процесс «Выполнение» сотрудник регистрирует фактические отрезки времени, потраченные на задачу, но эта информация не попадает в УНФ и никак не влияет на взаиморасчеты с клиентом.

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

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

 

Результаты внедрения

 

 

В результате внедрения системы учета задач у нас получился интересный эффект – выработка (количество регистрируемых часов) увеличилась в 1.5-2 раза! Мы смогли выявить скрытые часы, за которыми скрывалась недополученная прибыль. Как нам это удалось?

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

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

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

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

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

Таким образом программисты стали меньше времени тратить на постановку и сдачу задачи и смогли вырабатывать в 1.5-2 раза больше – как раз за счет того, что выявились эти скрытые часы.

 

Как выглядит наша система для управления разработкой

 

 

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

 

 

Внутри задачи указывается:

  • вся аналитика, которая нужна разработчикам – конфигурация, тип работ, разбивка по проектам;

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

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

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

 

 

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

 

 

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

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

 

 

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

И есть набор различных отчетов.

 

 

Также мы сюда внедрили такое понятие, как выпуск релиза – по аналогии с выпуском обновления в СППР.

 

 

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

 

Планы

 

 

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

  • В УНФ существует блок CRM, но нам недостаточно функциональности, которая там есть, поэтому мы хотим интегрироваться с другой CRM-системой;

  • У нас работает BAS:Документооборот – это своего рода наш внутренний Confluence, база знаний, мы согласовываем в нем документы, счета, и он обменивается с УНФ договорами и счетами. Есть идея интегрировать BAS:Документооборот с «Управлением разработкой» для того, чтобы тоже можно было из задачи посмотреть спецификацию по работам.

  • Также мы собираемся интегрировать «Управление разработкой» с другими конфигурациями для разработчиков:

    • средства перевода, такие как 1С:Переводчик или 1С:SmartSync (SmartCat) – мы также разрабатываем конфигурации на разных языках;

    • СППР;

    • 1С:АПК;

    • конфигурации для тестирования, в которых запускается Vanessa Automation и т.д.

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

 

Выводы

 

 

Какие выводы я хочу сделать:

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

  • Идеально подходящей вам системы учета задач не существует – все активно хвалят стек Atlassian, но нас Jira все-таки не устроила, поэтому я думаю, что найти подходящую систему в готовом виде нереально. Зато вы можете создать такую систему самостоятельно на основе чего-то готового, а потом ее постоянно адаптировать и развивать.

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

 

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

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Инструментарий руководителя проекта". Больше статей можно прочитать здесь.

Приглашаем всех 11-12 ноября принять участие в INFOSTART EVENT 2021 в Москве: //infostart.ru/events/1451228/

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. serg33rus 09.07.21 14:20 Сейчас в теме
Чисто личное мнение и личный опыт по сравнению с другими системами управления проектами.
У меня не стоит задача "управлять проектом". У меня задача - управлять фирмой, которая занимается практически всем, что связано с IT. Тут и связь, и инет, и сервера, и видеонаблюдение, и скуд, и 1С само собой, и АТС. Т.е. есть набор разноплановых задач и набор спецов. И вот тут УЗ от Антона у меня "выстрелила". Чего я только не перебирал. Спринты у меня есть, но лишь в 20% задач, а остальные либо периодические, либо разовые по запросу. И классические типа JIRA не вытанцовываются. Это система помогающая "пасти котов". И без нее тяжко.
А если учесть что лично у меня сюда же приляпан сервер регистрации ошибок 1С и задача автоматом генерится. Туда же падают письма на support@. Туда же бот телеги присобачен. И уведомления сыпятся не только на почту или телегу, но и на анахронизм типа аськи, ну исторически так сложилось, что она используется в конторе.
А еще много задач рождается в процессе общения по телефону, а звонки у меня тоже фиксируются в системе с возможностью привязать звонок к задаче. Там же можно послушать разговор, чтобы понять откуда ноги растут. Там же оценить сколько общение сожрало времени.
У меня даже проходная падает в TASK в виде оповещения, чтобы понимать на территории специалист или в поле.
И это не предел. Если мне еще что-то понадобиться, я нарисую еще одно расширение. У меня даже связка с бух работает, чтобы поймать оповещение что бабки по счету пришли.
И небольшая База знаний там же. И файлы удобнее в БЗ хранить поскольку полнотекстовый поиск работает и по файлам.
И аналог системе я не найду. Если только самому писать.
В общем как система управления проектом по созданию ПО наверно не самая сильная вещь. Как система управления задачами в конторе (разноплановыми задачами) ей цены нет. я сейчас без нее просто сдохну. Ну или сам застрелюсь.
Все вышеизложенное является частным мнение отдельно взятого руководителя отдельно взятой конторы.
rovenko.n; drmaxart; +2 Ответить
2. o.nikolaev 204 10.07.21 14:27 Сейчас в теме
Потом вы можете проанализировать это потерянное время и выставить эти часы клиенту, чтобы не было недополученной прибыли.
Про вот это можно подробнее? За что в данном случае заплатит клиент?
3. o.nikolaev 204 10.07.21 14:33 Сейчас в теме
наш внутренний Confluence, база знаний, мы согласовываем в нем документы, счета, и он обменивается с УНФ договорами и счетами.

Что-то как-то у вас все смешалось: Confluence, база знаний, согласование документов, учет договоров, учет счетов. Вы уверены что этот склад разнородных данных тыкаемых разносмешанными процессами можно назвать "базой знаний"?
4. Rustig 1834 23.07.21 13:05 Сейчас в теме
(0)
В результате внедрения системы учета задач у нас получился интересный эффект – выработка (количество регистрируемых часов) увеличилась в 1.5-2 раза! Мы смогли выявить скрытые часы, за которыми скрывалась недополученная прибыль. Как нам это удалось?

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

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

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

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

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


Клиент все равно заплатит за работу аналитика, тестировщика, менеджера проекта - так отдали бы эти деньги программистам, которые кроме разработки также по телефону консультируют...

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

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


Спасибо за доклад.
Оставьте свое сообщение

См. также

Как настроить правильную техподдержку (helpdesk, service desk на коленке) Промо

Управление услугами и сервисом Управление взаимоотношениями с клиентами (СRM) Документооборот и делопроизводство Монитор заказов Учет рабочего времени Управление взаимоотношениями с клиентами (СRM) Документооборот и делопроизводство Монитор заказов Учет рабочего времени v8 УУ Бесплатно (free)

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

24.04.2019    26922    siddy    0    

Удаленные сотрудники: учет и систематизация работы

Управление проектом Управление персоналом (HRM) Учет рабочего времени Управление персоналом (HRM) Учет рабочего времени УУ Бесплатно (free)

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

14.08.2019    5344    primat    23    

Автоматизация для "полевых" сотрудников (тех, кто не работает в офисе)

Управление бизнес-процессами (BPM) Учет рабочего времени Учет рабочего времени v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса УУ Бесплатно (free)

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

24.01.2018    15648    siddy    0    

Бесплатный GPS-трекинг Промо

Интеграция Управление персоналом (HRM) Учет рабочего времени Управление персоналом (HRM) Учет рабочего времени Бесплатно (free)

Современные технологии и возможности становятся все более доступными для широких масс и повсеместно используемыми, как для частного лица, так и для мелкого и среднего бизнеса. Так и GPS-трекинг (отслеживание в реальном времени на карте местоположения водителей, курьеров, монтажных бригад, торговых представителей, детей, собак и т.п., а также просмотр статистики по их передвижениям и остановкам), становится сейчас все более востребованным сервисом, как для домашних условий, так и для предприятия. И, если крупные фирмы (например, транспортные предприятия) подписав договора с коммерческими сервисами, оплачивая своевременно счета за устройства и абонплату, эту проблему для себя решили, то это скорее подходит для крупных корпоративных клиентов. Что делать нам, простым смертным или небольшой фирме с несколькими водителями, например? Какие есть простые, надежные и недорогие решения?

05.01.2013    49744    venger    19    

Одна из причин медленной работы табеля (ЗУП 2.5, клиент-сервер, MS SQL Server)

Практика программирования Статистика базы данных Производительность и оптимизация (HighLoad) Учет рабочего времени Учет рабочего времени v8 ЗУП2.5 Россия Бесплатно (free)

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

19.01.2016    23380    KAPACEB.AA    19    

Контроль рабочего времени - синхронизация СКУД LYRIX с базами 1С: ЗУП

Практика программирования Учет рабочего времени Учет рабочего времени v8 ЗУП2.5 Россия УУ Бесплатно (free)

Часто бывает необходимо анализировать не просто данные с считывателей карт прохода в офис, но анализировать в режиме сопоставления с кадровыми данными 1С: ЗУП. Актуальна также задача учета причин отсутствия и их визирования начальниками отделов. Существует простое решение на веб-клиенте 1с, с помощью объекта ВнешниеИсточникиДанных. Однако оно не обладает гибкостью - под каждые новые базы нужна перенастройка. По представленному описанию решение может быть легко воспроизведено для любых источников данных.

12.12.2014    13581    nano1c    13    

Общие принципы формирования графика производства в новом решении "1С: ERP Управление предприятием 2.0"

Управление бизнес-процессами (BPM) Бухгалтерский учет Финансовый учет и бюджетирование (FRP) Учет рабочего времени Финансовый учет и бюджетирование (FRP) Учет рабочего времени v8 ERP2 УУ Бесплатно (free)

Во второй статье, входящей в серию материалов, посвященных модулю производственного планирования в новом решении "1С:ERP Управление предприятием 2.0", рассматриваются особенности настройки графиков производства, в том числе интервалы планирования, расчет графика производства на верхнем уровне и выполнение графика на нижнем уровне.

21.07.2014    31524    itrp2013    2    

«Тайм-менеджер по помидорам» - эффективная организация рабочего времени.

Учет рабочего времени Личная эффективность Учет рабочего времени Россия Бесплатно (free)

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

30.07.2013    36368    LexSeIch    49    

Ой, инвентаризация, чтоб её…

Бухгалтерский учет Розничная торговля Учет рабочего времени Учет ТМЦ Розничная торговля Учет рабочего времени Учет ТМЦ Розничная и сетевая торговля (FMCG) Россия Бесплатно (free)

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

06.05.2013    13708    AlexanderEkb    34    

Работа с PerCo своими силами

Внешние источники данных Учет рабочего времени Учет рабочего времени v8 1cv8.cf Россия Бесплатно (free)

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

03.10.2012    32652    Nas'ka    25    

Выгрузка данных в MS-Project

Загрузка и выгрузка в Excel Внешние источники данных Учет рабочего времени Учет рабочего времени v8 1cv8.cf Бесплатно (free)

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

29.12.2009    14517    dolter    3    

В помощь кадровикам, работающим на ЗиК 7.7

Практика программирования Учет рабочего времени Учет рабочего времени v7.7 1С7:ЗиК Россия БУ УУ Бесплатно (free)

В помощь кадровикам, работающим на ЗиК 7.7 при оформлении документов прием на работу и кадровое перемещение

07.04.2009    8023    @lex    1