Павел Ларкин

Уязвимости можно найти в любой системе, все зависит от знаний и кошелька злоумышленника

В России существует не так много решений, которые в принципе можно использовать. Да, есть AmoCRM, 1С CRM и, в том числе, Битрикс24 — можно выбрать на любой вкус. Мы сами пользуемся Битрикс24 уже много лет, видим недостатки, но альтернатив действительно немного.

А такие компании, как мы, могут сгладить многие шероховатости и попробовать подстроить "коробочное" решение под нужный запрос (почти что напильником :)

обращайтесь:)

У нас не было задачи придумать идеальную систему учета рабочего времени. Заказчик захотел привязать учет именно к работе компов, результат его полностью устроил. Такое решение отличная замена "СКУДа на минималках".

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

Спасибо за статью! В мемориз!

Отличный кейс! Лайк!

Олег, привет!  Спасибо за статью.
Можешь поподробнее раскрыть информацию о том сколько метров и "жопомест" было в старом и стало новом офисе? Из статьи я понял, что вы перевели часть команды на удаленку, а в офисе оставили тех кто не может\не хочет работать удаленно и места для для тех, кто приходит периодически? В общем, раскрой тему трансформации компании под условия удаленки, пожалуйста. :)

Мы пока не добрались полноценно до тестирования т.к. это отдельная тема. 

1. Каждый ответственный за процесс\отдел\направление отвечает за свои регламенты. Если необходимо что-то поправить в регламентах, то задача ставится именно на ответственного.
2. У каждого регламента описан ответственный в конце регламента. Т.е. всегда можно понять кто за него отвечает.
3. В каждом регламенте есть история изменений, кто изменения внес, какого числа и что конкретно поменял (выделяется желтым в тексте). Это позволяет контролируемо вносить и изучать изменения.
4. Те же СПОРЫ позволяют контролировать актуальность регламентов т.к. тот, кто открывает Спор, должен указать ссылку на регламент. Так же его перечитывает тот, на кого открыли спор. Так что еще есть 2 "контролера", которые могут сообщить о том, что регламент устарел или что он "дырявый".

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

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

1. Можно, но проще придумать костыль из правил наименования сделок. Например, есть услуга: "Хостинг домена ya.ru" Если договориться всегда писать услуги=названия сделки в таком формате, то потом очень просто любые штатные фильтры делать по ключевому слову из названия сделки, а так же вставлять прям название сделки в любые автоматические письма. Например, "Уважаемый клиент, Хостинг домена ya.ru отключен!" Причем для этой логики не важно что вы занесете в справочник т.к. она универсальна.

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

Илья, пройдя этот путь перенести все это ну другой портал можно за несколько часов. Т.е. на повторение пройденного пути требуется гораздо меньше времени. :)

Но вы, конечно же, правы. 

Судя по всему вы не дочитали статью. Цитирую из выводов:
Больше не нужна отдельная роль по контролю за инфраструктурными сделками. Даже если взять минимальную оплату такого человека в 40 000 рублей в месяц, то по году это экономия в 480 000 рублей! А сэкономил - считай заработал! :)

Алексей, есть вопросы по вашему комменту:
1. А какую задачу ставит скрипт? В штатном Битриксе есть счетчик, который загорается, если по сделке нет следующего дела. 
2. А почему не сделали штатной задачей "пингануть" заказчика через ХХХ дней или Ожидание ХХХ дней? ИМХО методологически не верно менять статус у таких сделок т.к. после 1 пинга может оказаться, что она еще отложена и ее трогать не стоит.
3. По-моему, есть модуль в маркетплейсе, который делает эту операцию. 

У нас все кассы проверяются бухгалтером и в ручную проставляются оплаты у счетов в CRM. Но для некоторых банков есть модули для Битрикс24, которые обещают автоматическое получение выписки по счету и распознавание счетов. Естественно, если в назначении платежа явно указан счет и сумму.

Василий, отвечу по пунктам:
1) Если приходит частичная оплата, то сценарий не идет дальше, пока счет полностью не будет оплачен. Т.е. если домен, условно, стоит 1000 рублей, то если оплатят 500 руб, то ничего не произойдет (кроме статуса счета, что он оплачен частично). Как только поступит полная оплата по счету, то сработает триггер и сделка переведется в "Продление". А если полной оплаты не поступит, то услуга будет отключена.
2) Обезличенная оплата или оплата сразу по нескольким счетам это всегда геморрой. :( Ну скорее это всегда геморрой для бухгалтера, который разносит платежи и ему приходится угадывать за что была оплата. И это проблема платежной дисциплины со стороны клиента ибо во всех счетах написано красным по белому - указывайте номер счета, который оплачиваете. Как правило, это быстро лечится, когда отключишь 1 раз такого клиента с формулировкой "Автоматика не распознала ваш платеж и отключила. Ваш же просили в каждом платеже указывать реквизиты счета." Для адекватных заказчиков этого достаточно. :)

А для описанной системы все равно - триггеры на оплату срабатывают только когда у связанного со сделкой счетом меняется статус на ОПЛАЧЕН.