Вопрос

Добрый день.
Помогите пожалуйста разобраться.
Менеджер заводит нового контрагента. Если тип у этого контрагента остается "Потенциальный клиент", то нужно создать для этого менеджера задачу со статусом Выполнена, длиетельностью 2 минуты со стандартным Title-ом и с привязкой к этому контрагенту.

В скрипте scr_AccountEdit в функции
пишу следущее

function btnOKOnClick(Control) {
        if (!CheckAccountData()) {
            return;
        }
//Начало моей правки
debugger;

   if (edtAccountType.DataField.DisplayValue=='Потенциальный клиент') {
        var Attributes = new ActiveXObject('Scripting.Dictionary');
        var DefaultValues = new ActiveXObject('Scripting.Dictionary');
        DefaultValues.Add('Title','Первоначальный звонок клиенту');
        var CurrentTime = new Date(System.Now());
        CurrentTime.setMinutes(CurrentTime.GetMinutes+2);    
        DefaultValues.Add('DueDate',CurrentTime.getVarDate());
        var prior = GetDictionaryIDByName('Tasks\\Dictionaries\\Priority\\ds_TaskPriority', '2.Средний');
                DefaultValues.Add('PriorityID', prior);
        var statusid=GetDictionaryIDByName('Tasks\\Dictionaries\\Status\\ds_TaskStatus', 'Выполнена');
        DefaultValues.Add('StatusID',statusid);
        DefaultValues.Add('AccountID',edtName.DataField.Value);
            ShowEditWindowEx('wnd_TaskEdit', Attributes, DefaultValues);
           
        }  
// конец моей правки

        scr_BaseDBEdit.btnOKOnClick(Control);
}

и система вываливается ...
Подскажите что я не так делаю

У меня такой же вопрос

10 комментариев

Обнаружил точно из-за чего не работает...

function btnOKOnClick(Control) {
	if (!CheckAccountData()) {
	    return;
	}
//Начало моей правки
debugger;
//  	var Dataset = DataField.ParentDataFields.ParentDataset;
//    if (Dataset.DisplayValues ('edtAccountTypeID') == 'Потенциальный клиент'){
   if (edtAccountType.DataField.DisplayValue=='Потенциальный клиент') {
        var Attributes = new ActiveXObject('Scripting.Dictionary');
        var DefaultValues = new ActiveXObject('Scripting.Dictionary');
        DefaultValues.Add('Title','Первоначальный звонок клиенту');
        var CurrentTime = new Date(System.Now());
        CurrentTime.setMinutes(CurrentTime.GetMinutes+2);     
//        DefaultValues.Add('DueDate',CurrentTime.getVarDate());
        var prior = GetDictionaryIDByName('Tasks\\Dictionaries\\Priority\\ds_TaskPriority', '2.Средний');
		DefaultValues.Add('PriorityID', prior);
        var statusid=GetDictionaryIDByName('Tasks\\Dictionaries\\Status\\ds_TaskStatus', 'Выполнена');
        DefaultValues.Add('StatusID',statusid);
//        DefaultValues.Add('AccountID',edtName.DataField.Value);
  	    ShowEditWindowEx('wnd_TaskEdit', Attributes, DefaultValues);
 
  	}  
// конец моей правки
 
	scr_BaseDBEdit.btnOKOnClick(Control);
}

Вот так работает... но соответственно не все заполняет...

//        DefaultValues.Add('AccountID',edtName.DataField.Value);

Это просто глупость... ;-))

Сделал для контрагента вот так:

 var AccountID = GetAttribute(Self, 'RecordID');
 DefaultValues.Add('AccountID',AccountID);

все проходит, но Контрагент не заполняется...

C датами тожке разобрался

        var CurrentTime = new Date(System.Now());
         CurrentTime.setMinutes(CurrentTime.getMinutes()+2);     
        DefaultValues.Add('DueDate',CurrentTime.getVarDate());

Вобщем осталось две проблемы.
1. Так и не заполняется Контрагент.
2. Как сделать так, чтобы окно с зачачей закрывалось само с сохранением.

Контрагент заполняется... проблема была в том что
строка
scr_BaseDBEdit.btnOKOnClick(Control);

должна быть перед

ShowEditWindowEx('wnd_TaskEdit', Attributes, DefaultValues);

.

Осталось только закрывать задачу.
Копать наверное нужно в сторону Notify. ???

В вашем случае не надо показывать карточку, достаточно создать Dataset для таблицы задач, сделать ему Append, заполнить нужные поля значениями и сделать Post.

Примерно, это должно выглядеть следующим образом:

// AccountTypeID - константа из справочника типа контрагентов.
	if (Dataset('AccountTypeID') == AccountTypeID){
		var TaskDataset = Services.GetNewItemByUSI('ds_Task');
                var AccountID = Dataset('ID');
		ApplyDatasetFilter(TaskDataset, 'ID', GUID_NULL, true);
		TaskDataset.Open();
		TaskDataset.Append();
			//Здесь  заполняете все необходимые Вам поля
			TaskDataset('AccountID') = AccountID; 
			TaskDataset('StatusID') = 
		TaskDataset.Post();
		TaskDataset.Close();
	}
Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

БП продажи
Задача: Создать N-счетов, для каждого созданного счета создать задачу, переводить продажу в состояние "Завершена" только после завершения всех задач, если хотя бы одна задача с отрицательным результатом - отменять продажу.

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

У меня такой же вопрос

4 комментария

Вам нужен элемент "Слияние" (треугольник) в редакторе БП.

Я бы точно мог его использовать, если бы количество задач было заранее известной константой. я бы нарисовал, допустим, 10 задач и направил бы это в слияние - отлично. Но я не знаю сколько будет задач, так как это указывает пользователь для каждого договора в процессе выполнения БП

Добрый день!

Занимался когда-то похожей задачей.
нашел сервисы процесса (во вложении).
Суть в том, чтобы проверять количество завершенных и не завершенных подпроцессов.
services.rar
сервисы для версии 3.3.1.148 (MSSQL)

Спасибо за ответы, уже натолкнули коллеги на решение - В элементе "Скрипт" создать в цикле все задачи и перейти в следующий элемент "Скрипт", где запросом проверять статус задач и по результатам выставлять текущему WorkflowItem(наш элемент "Скрипт") параметр IsCompleted в true или false. Запускать этот элемент каждый раз когда изменяем задачу данного БП.

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

Здравствуйте, коллеги! Вопрос такой. Как добавить колонку "Должность" в окне выбора контакта в Задаче? Какой порядок действий?

У меня такой же вопрос

2 комментария

Надо открыть в TSAdmin сервис ds_Contact, полю JobID поставить галку "Поле для отображения" и сохранить.

Спасибо, Александр! Получилось!:smile:

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

Добрый день!
Есть бизнес-процесс, в ходе которого создаются когда последовательно, когда параллельно
ряд задач.
Необходимо после создания каждой задачи, а также после ее выполнения посылать
e-mail уведомления ответственному и автору.

Как решить эту задачу, используя блок "Отправка E-mail" в бизнес-процессе.
В частности, какие параметры нужно указать в самом блоке,
и где, в какой момент заполнять параметры "ответственный", "автор" - кому отправить
и id задачи, по которой нужно отправить информацию?

Спасибо.

У меня такой же вопрос

3 комментария

Здравствуйте, Дарья.

Отправил ответ Вам на e-mail.

"Олейник Дмитрий" написал:

Отправил ответ Вам на e-mail.

С уважением,
Олейник Дмитрий
Эксперт 3-й линии поддержки


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

В качестве решения предлагается использовать SendEmailByTemplate из scr_MailUtils:

Отправлять примерно так:

var AddressList = [];
var OwnerID = Dataset.Values('OwnerID');
GetMailAddressesByContactID(OwnerID, AddressList);
var TemplateID = GetSystemParameterValueEx('IncidentEmailByContactTemplateID');
if (IsEmptyGUID(TemplateID)) {
   return;
}
var ID = Dataset('ID');
SendEmailByTemplate(TemplateID, {RecordID: ID, Address: AddressList,
    Silent: true, AutoSend: true});
Войдите или зарегистрируйтесь, чтобы комментировать
Вопрос

В бизнес-процессе используется 2 слияния. Примерная схема вот:
ошибка слияния
одно слияние работает корректно (левое), а второе -- не срабатывает, то есть при выполнении обеих задач процесс дальше не идет.
в чем может быть причина? или нельзя в бп использовать 2 слияния?
test.rar

версия бд-- 3.4.0.81,
бинарные файлы -- 3.4.0.114
субд -- скьель 2005

У меня такой же вопрос

3 комментария

Здравствуйте!

Попробуйте следующим образом: (сервис во вложении)

1

Дмитрий, спасибо за Ваш ответ!

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

я немного по-другому решила проблему (как всегда -- стоит задать вопрос -- так сразу приходит решение:smile:):
решение:)
то есть, я просто использовала элемент "скрипт" (ничего в него не прописывала, он пустой)
test.rar

Здравствуйте, Ольга.

Ветка результата "любой" после создания первой задачи и моделирует "параллельность" создания задач, т.е. в моем примере обе задачи будут при любых обстоятельствах созданы. И дальше, в зависимости от статуса по ним, БП пойдет по разным веткам до разных точек слияния.
Рад что у Вас получилось реализовать Вашу задачу самостоятельно и спасибо за публикацию решения!

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

Как лучше реализовать наследование задач? Например, я ставлю задачу руководителю отдела, а он на ее основе формирует еще три задачи различным сотрудникам, одному что-то уточнить, другому позвонить, третьему кофе сделать.

У меня такой же вопрос

4 комментария

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

Один из вариантов - небольшой бизнес процесс.

пока не представляю, как это можно реализовать в рамках бизнес процесса

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

Простой пример:
Вы ставвите задачу руководителю "Встреча" состояние задачи "Новая", Руководитель открывает задачу, просмотривает данные по встрече и меняет состояние на "Согласована". После чего задается вопрос, какие дополнительные задачи нужны к этой встречи (множественный выбор из списка - элемент БП). "Кофе", "Подготовить план встречи", "подтвердить встречу", "Встреить гостей". Используя параметры БП в качестве флагов и счетчиков, запрещаем переводить основную задачу в конечное состояние без выполненных вспомагательных задач.

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

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

У меня была не одна задача, поэтому использована конструкция switch. Некоторые задачи "зависели" от ключевой даты не "прямо", а, например, нужно было их поставить за 1 или 2 дня до нужной даты. Это тоже описано в примере.

Примечания. Имя ActionItem.Name-- элемент задачи в диаграмме, для которой дату “отсчета” начала задачи (ExecuteDate) нужно поменять. Дата берется из параметров диаграммы (TaskStartDate). По умолчанию дата вычисляется "стандартно”.

Что интересно -- все механизмы вычисления окончания задачи остаются такими же, то есть из карточки задачи (в бп) можно настроить продолжительность задачи.

switch (ActionItem.Name) {
   case  ('Task1'):   //задача, для которой началом есть дата1 --  дата из параметра  
        var Diagram = GetDiagramByItem(ActionItem);
        var ExecuteDate = WFGetParamValue(Diagram, 'TaskStartDate');
   break;
   case ('Task2'):   //дата2 -- за 2 дня до предыдущей даты
        var Diagram = GetDiagramByItem(ActionItem);
        var ExecuteDate = WFGetParamValue(Diagram, 'TaskStartDate');
        ExecuteDate = AddDateDays(new Date(ExecuteDate), -2, true).getVarDate();
   break;
   default:
        var ExecuteDate = ItemDataset.ValAsDateTime('ExecuteDate');
   break;
}

этот "кусок" кода нужно вставить вместо строчки

var ExecuteDate = ItemDataset.ValAsDateTime('ExecuteDate');

в скрипте wa_TaskAction.

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

в функции BuildDataControl(Window, ParentComponent, DatasetLink, DataField)
добавить (где-то в конце, после создания компонента)

//----для даты -- тип контрола дата/время
        if (ComponentType == 'DateTimeDataControl') {
                Component.Kind = dtkDateTime;  
        }
//----

Поделиться

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

В конфигурации отправка описана в скрипте scr_TaskUtils в функции function SendTaskEmailToContact(TaskDataset, AddressList)

Таким образом, Вам необходимо доработать функцию следующим образом:

function SendTaskEmailToContact(TaskDataset, AddressList) {
         if (GetDatasetFieldValue(TaskDataset, 'CycleTaskParamID')) {
                   var TemplateID = GetSystemParameterValueEx('CycleTaskEmailByContactTemplateID');
         } else {
                   var TemplateID = GetSystemParameterValueEx('TaskEmailByContactTemplateID');
         }
         if (IsEmptyGUID(TemplateID)) {
                   ShowErrorDialog(FormatStr(SystemParameterIsEmptyError,
                            'TaskEmailByContactTemplateID'));
                   return;
         }
         var ID = TaskDataset.Values('ID');
                   
         var FileName = System.CreateObject('TSObjectLibrary.Value'); //создаем объект файл
         FileName.Value = 'C:\\Test.rtf'                                             //определяем путь хранения временного файла
         TaskDataset.DataFields('Description').SaveToFile(FileName.Value);  //сохраняем описание в файл
         var Attachments = new Array(FileName.Value);                           //определяем, что данный файл будет аттачем
         
         var Service = Services.GetSingleItemByUSI('scr_MailUtils');
         Service.ScriptControl.CodeObject.SendEmailByTemplate(TemplateID,
                   {RecordID: ID, Address: AddressList, AutoSend: true,
                   SkipQueryAddresses: true, Attachments: Attachments}); //в этой строке добавлены аттачи
}

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

1. Откройте sq_Task и добавьте новую колонку Description:

img125
img126

Сохраните и закройте запрос.

2. Откройте датасет ds_Task и добавьте в него колонку типа большой бинарный объект:

img127
img128

Сохраните и закройте датасет.

3. Откройте scr_TaskUtils и внесите изменения в функцию отправки письма. Перезапустите клиент. Результат будет выглядеть следующим образом:

img129

Поделиться

1 комментарий

о, спасибо :biggrin:

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

Коллеги!
Подскажите примерный код функции автоматического связывания элементов проекта (аналог кнопки установить связь между элементами проекта). При этом нужно автоматически пересчитать даты стадий и связанные с проектом задачи?
Возможно есть готовая функция или несколько функций для этого?
Заранее спасибо!

У меня такой же вопрос

1 комментарий

Вот часть скрипта, которая выполняется по кнопке "Связать элементы" (обработчик действия amiConnectElementsOnExecute в скрипте wnd_ProjectGanttAreaScript):

	var SelectedIDsArray = GetSelectedItemsIDsArray();
	if (SelectedIDsArray.length == 0) {
		ShowWarningDialog("Элементы не выбраны");
		return;
	}
	ConnectProjectElementsArray(Self, SelectedIDsArray, AreaObject);
	RefreshDataset(dlData.Dataset);

Основная функция связки - ConnectProjectElementsArray, которая вызывает AddProjectDependence из скрипта scr_ProjectDependenceUtils.

Пересчёт элементов выполняется функцией DoElementCalculation скрипта scr_ProjectElementLibrary. Посмотрите её реализацию, а также реализацию функций DoChildElementsCalculation и DoParentElementCalculation.

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

Статья посвящена отдельным проблемам управления процессом.
Тезис: Управление процессом возможно при осуществлении связи контроля и коррекции.
Проблема: Технологичный контроль (и как следствие коррекция) в некоторых случаях затруднителен.
Решение:

  1. Перенос функций контроля на участников процесса (взаимный контроль)
  2. Нормализуется не задача, а результат, к которому она приводит.
  3. Мотивация привязвается к результатам работы

Регуляция процесса и задачи контроля

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

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

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

Ограничение механизмов контроля.

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

Проблема уникальности задачи.

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

Проблема изменчивости критериев.

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

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

Анализируя возникающие в работе кейсы можно увидеть, что на самом деле есть две проблемы:

  1. Заинтересованность в результате
  2. Необъективность контроля

Проблема заинтересованности

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

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

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

Проблема контроля и ответственности

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

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

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

Риски и решения:

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

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

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

Поделиться

6 комментариев

Саша!
Мне кажется, нужно больше структурировать материал. Может даже стоит разбить его на несколько глав.
Мне, например, твой текст трудно читать, а из-за этого возникают трудности с пониманием.
Я думаю, что ты согласишься, что хорошая подача материала - залог успеха. Поработай над формой:)

Согласен с Инной. Не хватает тезисов и разбивки статьи на части. Статья интересная, но "ниасилил".

Спасибо. Я пока только разбираюсь с тем как писать посты. То что вы видите - черновик. Обязательно подправлю.

Хочу сделать дополнение к теме индикаторов контроля.

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

О каком уровне разработки критериев оценки идет речь, Александр? Ведь разработка потребителями критериев качества будет приводить к лоббированию интересов потребителя без понимания процессов рамок, сроков, ресурсов исполнителя. Или ты имел ввиду что-то другое?

Юра,
Естественно выработка критериев качества - двухсторонний процесс, исполнитель всегда имеет право отклонить необоснованные (или недостижимые) требования. Но интерес потребителя первичен - он предъявляет исходные требования к качеству работы.

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

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

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