Это просто перекладывание дополнительной выручки, которая образовалась из-за роста эффективности труда, в карман владельца. Нельзя его в этом обвинять :).
Спасибо! В других отраслях люди пользуются и не жужжат. Не везде вопросы слежки за сотрудниками актуальны. Во многих (конкурентных, конечно) видах бизнеса Планадо наоборот облегчает жизнь рядовым сотрудникам: они оперативно получают всю необходимую информацию о заказе, уменьшается количество созвонов с офисом. Если система оплаты сдельная, то сотрудник начинает больше успевать за то же время и, как следствие, больше зарабатывать.
> кабельщику списывать кабеля на 50 м больше,
Приложение умеет хранить доппараметры. Делаем доппараметр у наряда «Расход кабеля», ставим в чеклист наряда обязательный пункт «Указать расход кабеля». Суммируем значения полей по закрытым за неделю нарядам, сравниваем с отгрузкой со склада — сразу видим всю картину, кто сколько утащил. Конечно, можно и такую систему обмануть, но это уже на порядок сложнее. Монтажники — простые ребята, обязательно где-нибудь да спалятся.
> сантехнику поставить отказ в трекере и за 15 минут на месте решить проблему, положив деньги себе в карман?
Такую штуку можно провернуть раз, можно два, но рано или поздно (скорее рано) жадность погубит. Этих умников сразу видно по статистике отказов, она у них получается существенно выше, чем у честных сотрудников.
> И с новичками работа, как я понимаю, проводится постфактум, то есть, сперва он делает как считает лучше, а потом по фотографиям мы ему сообщаем, что так делать не надо было
Ну, если работодатель такой дятел, что необстрелянных бойцов бросает в бой в одиночку, то ему никакое приложение не поможет. Хотя чеклист для каждого типа наряда будет, это хоть какая-то помощь. Фотоотчеты нужны скорее для того, чтобы создать у сотрудника четкое понимание: схалтурил — огребешь.
Посоны, спасибо за обзор и отзывы. Не берите webtranslateit. Мы им пользуемся для перевода Гидры и ненавидим. В этот посте я оказался в поисках замены. Это французский сервис со всеми вытекающими странностями в интерфейсах. Но это ладно, человек — скотина терпеливая и даже к французской логике привыкает. Уи.
Беда в том, что он тормозной и интеграции с гитхабом нет. Окей, интегрируемся через API. API глючный, кучу времени на него убили, но так и не получилось ничего. Техподдержка не ответила. Сам сервис не развивается последние несколько лет. Стоит дорого. Терпение кончилось, когда количество ключей подошло к лимиту, а следующий тариф у них стоит еще вдвое дороже текущего.
Все что найдете в Activiti – всё ваше :). Конечно же, ничего подобного там нет, остается только ковыряться в XML/YaML-диффах в репозитории и смотреть коммит-логи и трекер.
Похоже, вам не повезло :). Если основной геморрой — это UI, а сами процессы несложные и редко меняются, то, конечно, BPMS не нужна и помимо раздолбайства есть только одна причина использования BPM-движка — распил.
Конечно же, адские BPMS позволяют делать все эти вещи, но их и покупают за адские деньги, чтобы делать адски сложные процессы. И при всем описанном вами геморрое использовать BPMS все равно будет дешевле, чем программировать (а потом постоянно изменять) бизнес-логику.
Есть два способа синхронизации НСИ. Первый — вручную (варианты выбора зашиваются в конфиге мастера). Понятно, что это для редко обновляемой информации. Второй способ — вообще не синхронизировать информацию, а подсасывать ее на лету из внешней системы в момент рендеринга формы. Так работает сейчас интеграция OMS с обычной Гидрой (биллингом).
1) Встраиваешь BPM-виджет в CRM.
2) Настраиваешь бизнес-процессы.
3) Запускаешь бизнес-процессы прямо из CRM. Мастер выполнения БП появляется, например, в виде всплывающих окон.
4)…
5) Профит.
Не уверен, можно ли это встроить в 1С, если речь не о веб-интерфейсе :).
А вот и не опаньки! Прямо сейчас в Гидру OMS встроен плагин для извлечения информации из RDBMS посредством настраиваемого в конфиге SQL-запроса (маленький нюансик: пока поддерживается только Oracle). И есть два типа лукапа — один в виде обычного комбобокса, а второй для подбора из большого количества вариантов. И можно добавлять свои типы полей и справочного текста.
Вообще, главной причиной создания Гидры OMS было то, что у всех изученных нами BPMS отсутствует возможность вменяемо настроить/допилить/встроить мастер выполнения «ручных» задач бизнес-процесса, не написав при этом миллиона строк кода на джаве.
TL;DR: Возможность подгружать на форму задания информацию из внешней системы, необходимую сотруднику для исполнения задачи — критически важная фича Гидры OMS, она уже есть и мы планируем развивать ее дальше.
Полностью с вами согласен. Могу только добавить, что как только стало понятно, что ситуация ухудшилась, инженеры имели возможность удалить все, что скопилось во входящих очередях. Прямо сейчас не могу выяснить, что именно они сделали, когда ухудшение стало заметно, но скорее всего так и поступили. То есть это действие было обратимым.
Я думаю, пара порядков у нас еще есть в запасе. Выборки из монги делаются очень примитивные, по индексу и с высокой селективностью. Изменения в базе происходят не слишком часто и применяются последовательно.
Не меньшее количество шлепков ладони по лицу прозвучало и при написании статьи. К сожалению, не у всех компаний есть желание вкладываться в инфраструктуру (и понимание, зачем вообще это делать), так же как ограничены и наши возможности влияния на клиента. Конечно же, хотелось добавить в статью несколько эмоциональных оценок, и первоначально они даже в ней были, но злобное начальство подвергло статью цензуре перед выпуском и предоставило воображению читателю самому додумать, какие монологи и диалоги происходили в процессе решения проблемы.
Что касается действий наших инженеров, то тут все не так просто. Разумеется, они знают, что в случае аварии можно разрешить авторизацию всем, но не на всех инсталляциях Гидры существует техническая возможность это сделать. Например, когда сервер авторизации выдает на BRAS IP-адрес абонента, а этот адрес серый и жестко закреплен за абонентом и если его не выдать, то нормально услуги предоставляться не будут.
Вы скажете: так делайте же время от времени выгрузку всего необходимого в файл и при аварии используйте этот файл. И будете правы, только у каждого клиента этот файл будет свой, то есть нужно делать кастомизацию выгрузки. А будут ли за эту кастомизацию делать (или платить) те, кто мониторинг не хочет настраивать (или покупать)?
Короче, плана Б у клиента не было, поэтому в его отсутствие и при явных симптомах поврежденных данных попытка пропихнуть на RADIUS-сервер актуальные данные была, я считаю, оправдана.
Вот тут https://habrahabr.ru/company/latera/blog/267083/ мы подробнее описывали, что будет происходить с Гидрой при разнообразных отказах, в том числе и когда MongoDB навернется. А здесь — https://habrahabr.ru/company/latera/blog/280196/, почему мы вообще используем Mongo и как оно нам.
Что касается объемов, то данных там хранится немного, на типовой инсталляции размер базы не превышает 1 ГБ, т.е. до того размера, когда Mongo начнет отказывать, еще расти и расти.
Мониторинг мы предлагаем клиентам настроить самим по инструкции или купить наш готовый за деньги, но, к сожалению, далеко не все ответственно к этому относятся. Особенно это касается небольших операторов.
Безусловно, мониторинг нужен и, конечно же, клиенту об этом много раз говорили, писали, умоляли. Наш облачный мониторинг предлагали, но он же денег стоит — 3 тысячи рублей в месяц. И про сервисы говорили, что нужно разносить.
Приложение умеет хранить доппараметры. Делаем доппараметр у наряда «Расход кабеля», ставим в чеклист наряда обязательный пункт «Указать расход кабеля». Суммируем значения полей по закрытым за неделю нарядам, сравниваем с отгрузкой со склада — сразу видим всю картину, кто сколько утащил. Конечно, можно и такую систему обмануть, но это уже на порядок сложнее. Монтажники — простые ребята, обязательно где-нибудь да спалятся.
> сантехнику поставить отказ в трекере и за 15 минут на месте решить проблему, положив деньги себе в карман?
Такую штуку можно провернуть раз, можно два, но рано или поздно (скорее рано) жадность погубит. Этих умников сразу видно по статистике отказов, она у них получается существенно выше, чем у честных сотрудников.
> И с новичками работа, как я понимаю, проводится постфактум, то есть, сперва он делает как считает лучше, а потом по фотографиям мы ему сообщаем, что так делать не надо было
Ну, если работодатель такой дятел, что необстрелянных бойцов бросает в бой в одиночку, то ему никакое приложение не поможет. Хотя чеклист для каждого типа наряда будет, это хоть какая-то помощь. Фотоотчеты нужны скорее для того, чтобы создать у сотрудника четкое понимание: схалтурил — огребешь.
Посоны, спасибо за обзор и отзывы. Не берите webtranslateit. Мы им пользуемся для перевода Гидры и ненавидим. В этот посте я оказался в поисках замены. Это французский сервис со всеми вытекающими странностями в интерфейсах. Но это ладно, человек — скотина терпеливая и даже к французской логике привыкает. Уи.
Беда в том, что он тормозной и интеграции с гитхабом нет. Окей, интегрируемся через API. API глючный, кучу времени на него убили, но так и не получилось ничего. Техподдержка не ответила. Сам сервис не развивается последние несколько лет. Стоит дорого. Терпение кончилось, когда количество ключей подошло к лимиту, а следующий тариф у них стоит еще вдвое дороже текущего.
Все что найдете в Activiti – всё ваше :). Конечно же, ничего подобного там нет, остается только ковыряться в XML/YaML-диффах в репозитории и смотреть коммит-логи и трекер.
Похоже, вам не повезло :). Если основной геморрой — это UI, а сами процессы несложные и редко меняются, то, конечно, BPMS не нужна и помимо раздолбайства есть только одна причина использования BPM-движка — распил.
Конечно же, адские BPMS позволяют делать все эти вещи, но их и покупают за адские деньги, чтобы делать адски сложные процессы. И при всем описанном вами геморрое использовать BPMS все равно будет дешевле, чем программировать (а потом постоянно изменять) бизнес-логику.
Есть два способа синхронизации НСИ. Первый — вручную (варианты выбора зашиваются в конфиге мастера). Понятно, что это для редко обновляемой информации. Второй способ — вообще не синхронизировать информацию, а подсасывать ее на лету из внешней системы в момент рендеринга формы. Так работает сейчас интеграция OMS с обычной Гидрой (биллингом).
1) Встраиваешь BPM-виджет в CRM.
2) Настраиваешь бизнес-процессы.
3) Запускаешь бизнес-процессы прямо из CRM. Мастер выполнения БП появляется, например, в виде всплывающих окон.
4)…
5) Профит.
Не уверен, можно ли это встроить в 1С, если речь не о веб-интерфейсе :).
http://hydra-oms.com, там на главной кнопка Try Demo. Видеоуроков пока нет, но пошаговое описание настройки бизнес-процесса есть в документации.
Вообще, главной причиной создания Гидры OMS было то, что у всех изученных нами BPMS отсутствует возможность вменяемо настроить/допилить/встроить мастер выполнения «ручных» задач бизнес-процесса, не написав при этом миллиона строк кода на джаве.
TL;DR: Возможность подгружать на форму задания информацию из внешней системы, необходимую сотруднику для исполнения задачи — критически важная фича Гидры OMS, она уже есть и мы планируем развивать ее дальше.
Что касается действий наших инженеров, то тут все не так просто. Разумеется, они знают, что в случае аварии можно разрешить авторизацию всем, но не на всех инсталляциях Гидры существует техническая возможность это сделать. Например, когда сервер авторизации выдает на BRAS IP-адрес абонента, а этот адрес серый и жестко закреплен за абонентом и если его не выдать, то нормально услуги предоставляться не будут.
Вы скажете: так делайте же время от времени выгрузку всего необходимого в файл и при аварии используйте этот файл. И будете правы, только у каждого клиента этот файл будет свой, то есть нужно делать кастомизацию выгрузки. А будут ли за эту кастомизацию делать (или платить) те, кто мониторинг не хочет настраивать (или покупать)?
Короче, плана Б у клиента не было, поэтому в его отсутствие и при явных симптомах поврежденных данных попытка пропихнуть на RADIUS-сервер актуальные данные была, я считаю, оправдана.
Что касается объемов, то данных там хранится немного, на типовой инсталляции размер базы не превышает 1 ГБ, т.е. до того размера, когда Mongo начнет отказывать, еще расти и расти.
Мониторинг мы предлагаем клиентам настроить самим по инструкции или купить наш готовый за деньги, но, к сожалению, далеко не все ответственно к этому относятся. Особенно это касается небольших операторов.