Доброго времени суток, коллеги!

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

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

В итоге получим примерно следующее содержимое функции обработчика события:

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

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

Результат на скриншоте. Описание реализации в прикрепленном файле.

Для того чтобы в карточке «Задача» изменить время по-умолчанию в поле «Продолжительность» необходимо выполнить следующие действия:
1. Открыть Terrasoft Administrator.
2. Открыть сервис src_TaskUtils (Common \ Library).
3. В теле функции function GetDefaultTaskDueDateTime(StartDate) изменить исходный код на, к примеру, следующий.
К примеру,

4. Сохраните изменения и перезапустите клиентское приложение Terrasoft.

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

Реализовано таким образом: пользователь в разделе [Задачи] выбирает те задачи, которые ему необходимо закрыть, нажимает пр. кнопку мыши и в контекстном меню выбирает «Действия» > «Отметить выполненными»:

И выбранные задачи становятся выполненными. [Факт. дата начала] и [Факт. дата завершения] проставляются датами по плану.

1. В wnd_TasksWorkspace был добавлен ActionMenuItem:

2. На него наложено событие amiChangeStatusOnExecute:

3.

4. Сам скрипт scr_Consts необходимо добавить в Используемые скрипты scr_TasksWorkspace.

5. Функция GetSelectRecordsForChangeStatus выглядит следующим образом, находится также в scr_TasksWorkspace:

6. Остается сохранить изменения и перезапустить систему.

Возникла необходимость работать с задачами Lotus Notes из конфигурации Terrasoft по следующим пунктам:

• Создать задачу в Lotus Notes
• Удалить задачу из Lotus Notes
• Получить список задач текущего пользователя

Прежде всего нужно в настройках пользователя (Файл - Настройки - Настройки пользователя) на вкладке "E-mail" указать интеграцию с Lotus Notes, перегрузить клиент, затем там же в настройках пользователя на вкладке Lotus Notes указать путь к исполняемому файлу и файлу настроек (на машине должен быть установлен Lotus Client).
Последующие операции проводились на версиях Lotus Notes 8.5 и Terrasoft 3.3.2.220.

Инициализация
Для установки соединения с Lotus Notes потребуется scr_LotusUtils, а именно функция InitializeLotus(). При этом пользователю будет выдано окошко логина, а в атрибутах коннектора появится проинициализированный экземпляр коннектора Лотуса.
Если вызвать инициализацию по второму разу, то ничего не произойдет, поскольку в скрипте библиотеки прописана проверка на этот случай.
Итак, инициализация сводится к одной строчке

Создание записи в Lotus Notes
Вначале получаем почтовую базу Лотуса

При создании задачи (doc.AppendItemValue('Form', 'Task');) нужно заполнять несколько другие атрибуты создаваемого документа:

Очень полезно при создании записи сохранить ее уникальный номер в Лотусе. Этот номер можно впоследствии использовать для быстрого нахождения записи.

Удаление записи Lotus Notes
Процесс удаления намного короче (при условии, что сохранен уникальный номер UNID созданной ранее записи):

Получение всех записей текущего пользователя
Список записей будем получать из представления календаря Лотуса:

Замечания и конструктивная критика приветствуются.

В предыдущем посте я упомянул термин "нормализация" задач. Хочу пояснить, что имел ввиду и зачем.

Позвольте, в начале, уточнить определение технологичного процесса.

1. Это воспроизводимая последовательность задач, выполнение которых приводит к нужному результату.
2. Данная последовательность представляет собой инструкцию к действиям и описывает кратчайшие пути достижения результата в наиболее вероятных вариациях процесса.
3. Сотрудник является исполнителем процесса.
4. Каждая задача нормализована (определение см. ниже).
5. Процесс включает в себя схемы контроля и регуляции.

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

1. Это воспроизводимая последовательность результатов, достижение которых приводит к итоговому результату.
2. Данная последовательность включает в себя рекомендацию к действиям и описывает лучшие практики достижения результата.
3. Сотрудник является интерпретатором процесса.
4. Поскольку задачи не нормализованы, процесс включает в себя механизмы самообучения, взаимного контроля и саморегуляции.
5. Внешний контроль осуществляется по результатам.

Первый подход применим, когда у нас есть однозначная зависимость между выполнением задачи и получаемым результатом. Ключевым требованием такого процесса является возможность нормализации выполняемых задач. В этом случае от исполнителя не ожидается существенного «творчества» при выполнении задачи (у него для этого может не доставать компетенций). От него требуется строгое следование инструкции (например, скрипту: если ответ клиента такой «…», то делаем так «…» если другой, то эдак). Контроль и регуляция осуществляется руководителем.

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

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

«Нормальная» задача:

1. Конкретна (понятно что и как необходимо сделать)
2. Имеет одного ответственного
3. Нормативами ограниченна во времени
4. Имеет четкие (однозначные) критерии оценки
5. Предполагает определенную форму передачи результатов
6. Подразумевает некие требования к компетенциям исполнителя

«Нормальный» результат:

1. Может не иметь одного ответственного (?)
2. Подразумевает некие требования к компетенциям исполнителя
3. Ограничен во времени внешними условиями
4. Критерием оценки является факт достижения результата
5. Форма передачи результата определяется в каждом конкретном случае
6. Содержание работы, количество задач является «черным ящиком»

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

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

1. Люди
2. Технологии
3. Методология внедрения изменений (технологий)

Подробности ниже:

Люди:

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

1. Практики подбора персонала
2. Мотивация
3. Оценка компетенций и управление развитием
4. Построение отношений

Технологии:

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

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

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

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

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

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

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

Предлагаю в нашей работе выделить следующие технологии:

1. Продажи (коробок и проектов)
2. Реализации проектов
3. Вывод нового продукта (отраслевого решения)

Методология внедрения изменений

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

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