На сайте ведутся работы Задача про ввод разнородных данных | Продвижение магазинов, торговых сетей, оптовых фирм... | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
2010-08-15 15:52:35
Анна Буздыкина » Дмитрий Гончаренко

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

Основная проблема - это проблема ввода данных. Данные поступают в очень разной форме:

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

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

Поступает в день так полторы сотни заявок примерно. Если начинать их вбивать в компьютер должным образом (в базу), будет не то что очередь, а "пробка" и злые Клиенты.

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

Доброго здоровья,

2010-08-16 16:00:32
Дмитрий Гончаренко » Анна Буздыкина

Спасибо, Анна, за интересный пример.

Два вопроса:

1. Сколько позиций в среднем в одной заявке?

2. Это заявки на что? Каков профиль деятельности Вашей фирмы?


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

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

Я сам отработкой заказов давно не занимаюсь, но просто перенаправить их на своих сотрудников не всегда удобно (могут воспринять как невнимание с моей стороны), поэтому я делаю так:

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

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

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

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


Отсюда третий вопрос, вдогонку к первым двум: Какие подводные камни Вы видите в использовании такого подхода в Вашей ситуации?

2010-08-17 12:52:19
Анна Буздыкина » Дмитрий Гончаренко

Доброго здоровья!

Два вопроса:

1. Сколько позиций в среднем в одной заявке?

2. Это заявки на что? Каков профиль деятельности Вашей фирмы?

Позиций в заявке от 20-ти до 250-ти. Оборудование для продуктовых предприятий (производителей) и там большая номенклатура по комплектующим и проч.

Прилагаю состав заявки. Если она пришла по почте/аське. то копирую текст и вставляю в задачу.

Длинная ведь портянка получится и в день по сотне-полторы таких портянок. Неудобно в компьютере.

 

Если пришла "со скрепкой" - присоединяю этот же файл к задаче.

Присоединить дело нехитрое. Обрабатывать как потом? В каждую "скрепку" (файлы разного формата, открывающиеся в разных программах) заходить, ... Смерть.

Если длинная - могу на выбор либо отсканировать и присоединить в виде файла, либо просто написать в задаче "Заявку передаю в печатном виде"

Вот обрабатывать как этот скан? Перебивать данные с него вручную в базу? Это не подходит: вон их сколько и какие у них размеры.

Такие дела,

2010-08-17 15:45:49
Дмитрий Гончаренко » Анна Буздыкина

Здравствуйте, Анна!

Спасибо за ответы - с каждым разом задача становится все понятнее :)


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


Это я к тому, что человек, обрабатывая заявку, все равно вносит данные с нее в базу или в Excel, и проблема скорее всего не в этом, а в том, чтобы:

  • не забыть отработать заявку
  • сделать это в нужный (ожидаемый клиентом) срок.

Правильно? Или я чего-то не учитываю?



2010-08-17 18:57:51
Анна Буздыкина » Дмитрий Гончаренко

На выходе-то мы знаем, что получить. Выход-то унифицируем и Клиенту удобно читать в том, что мы пришлем. Мы ему и в "Оффербуке" пришлем (там же структура задается любая и можно импортировать хоть через xml).

Мы вход унифицировать не можем.

Это я к тому, что человек, обрабатывая заявку, все равно вносит данные с нее в базу или в Excel, и проблема скорее всего не в этом, а в том, чтобы:

  • не забыть отработать заявку
  • сделать это в нужный (ожидаемый клиентом) срок.

Вносит-то он вносит... Если бы...

Как Вы проадминистрируете "все равно внесение портянок"? Если часть их поступила, но не обработана, кто это увидит? Ваша система не "увидит", т.к. в нее не внесли. А проблемы с внесением я описала выше, так что повторяться не буду.

Часть сделок и немалая просто теряется. Некоторая (может и меньшая часть) вносится. А потом, потеряв 70% заявок (а никто не знает точно сколько), мы что будем радостно администрировать оставшиеся 30% ?

И эти 30% как обработать после того, как их внесли (о сложностях - см. в предыдущем сообщении)? Смотреть на них глазами, а потом вбивать данные в формы? А зачем мы их тогда вносили в компьютер? Вбивали бы уже "с листа". Но тогда будет пробка, как в Химках.

Доброго здоровья,

2010-08-17 21:43:53
Дмитрий Гончаренко » Анна Буздыкина

Не буду лезть с преждевременными советами. Лучше попробую уточнить Вашу ситуацию еще подробнее, если можно.

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

1.Сколько времени уходит на отработку заявки? Если можно, по формуле типа "15 минут + по 1 минуте на каждую строку заявки".

2. Сколько человек занимается отработкой заявок?

3. Правильно ли я понимаю, что человек, принявший заявку, ее же и отрабатывает? Либо принимают одни, а отрабатывают другие?


2010-08-18 09:19:58
Анна Буздыкина » Дмитрий Гончаренко

1.Сколько времени уходит на отработку заявки? Если можно, по формуле типа "15 минут + по 1 минуте на каждую строку заявки".

Предположим,

а) В заявке 1 имеем 50 позиций (и это не всегда строки). Предположим, Клиент прислал заявку по факсу, причем (и это видно) сделанную так:

  • он распечатал свою же заявку прошлого месяца;
  • вычеркнул из нее несколько позиций вручную;
  • дописал штук 15 позиций вручную;
  • в нескольких, оставленных с прошлого раза поправил цены;
  • добавил еще (вручную же) от себя "сопроводиловку" о том, какие условия хочет в этот раз и просьбу перезвонить "А то письменно долго объяснять";
  • после того, как ему "передозвонились" (мой фирменный термин!), он расказал еще немало и это все я записала во время разговора "на почеркушку" - т.к. вбивать это в компьютер без обработки долго, а Клиент на линии и его надо слушать, любезно отвечать и быстро от руки записывать, а не по "формам шарить" (когда он на связи);
  • итого имеем: его факс, память о телефонном разговоре и мою почеркушку;
  • теперь по логике, я должна это вбить в базу. Что это значит?
    • сесть подумать и разобраться в той номенклатуре о которой он поведал способами, описанными выше;
    • ту часть номенклатуры, которую я поняла (то есть, он назвал ее правильно по контрольным вопросам я убедилась, что путаницы нет) я должна выбрать из базы и сформировать часть заявки;
    • другую часть (и это не редкость), которуя я не смогла отождествить с тем, что есть у нас, я должна как-то оформить и отнести к консультантам в отдел закупки;
    • но как опишешь то, что до конца сам не понял?
    • поэтому идешь в отдел закупки и рассказываешь о том, что сказал Клиент;
    • они "чешут репу";
    • иногда перезванивают Клиенту, иногда сразу понимают и говорят: "Анна, это вот что" (иногда, при этом, они ошибаются, а фирма и я расхлебывают);
    • если мне сразу сказали "Вот что", я иду away и доформирую заявку;
    • иначе: "заявка болтается".

Это была одна заявка. Но пришло еще N. Например,

б) В другой заявке имеем 70 позиций. И она прислана в xls "скрепкой".



Пропускаю длинный ряд перечислений того, что приходится делать (Вы и сами представите)... в итоге: мне все равно надо выполнить все то, что выше маркировано "светлыми точками".



в) А тут еще одна в pdf и т.д.



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

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

2. Сколько человек занимается отработкой заявок?

 

Тридцать два.

  

3. Правильно ли я понимаю, что человек, принявший заявку, ее же и отрабатывает? Либо принимают одни, а отрабатывают другие? 

Ну, что значит "отрабатывают"? Работают над ней разные люди и разные отделы.

Доброго здоровья,

2010-08-18 10:56:48
Дмитрий Гончаренко » Анна Буздыкина

1. Насколько я понял из этого

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

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


2. Над заявкой работает тот человек, который ее принял + при необходимости (непонятные, новые позиции) сотрудники отдела закупки. Другие сотрудники и отделы в работе над заявками не участвуют. Правильно, или есть еще варианты?


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


4. Вы сказали, что над заявками работают 32 человека - это включая сотрудников отдела закупки или только те, кто непосредственно работает с клиентом, условно "продажники"? Если продажники - то получается 150 заявок/ 32 человека = примерно 5 заявок в день. Или тут другая арифметика?


2010-08-18 20:58:14
Анна Буздыкина » Дмитрий Гончаренко

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

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

2. Над заявкой работает тот человек, который ее принял + при необходимости (непонятные, новые позиции) сотрудники отдела закупки. Другие сотрудники и отделы в работе над заявками не участвуют. Правильно, или есть еще варианты?

 

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

Бывают варианты. Есть склад. И бывает, что часть позиций у нас есть, а часть надо дозаказывать. Конечно, остатки по базе я вижу и есть правила резервирования и проч. - так, что они ее, конечно, не создают заявку-то. Но когда заказ собирается из разных мест, надо смотреть за разными местами. Например, часть заказа идет со склада, часть везем прямо к Клиенту. Есть для этого диспетчирование, которым я не занимаюсь, но Клиент-то мне звонит и спрашивает: "Анна, где, блин, мой гофратор?" Иду узнавать где гофратор. Думаете я помню о чем он спрашивает? И мне некогда рыться - я сейчас обрабатываю другие заявки. Я просто звоню диспетчеру и некорректно спрашиваю (не называя номера заявки): "А где сейчас гофратор для Луганска?" Чтобы они меня не забыли, я им должна - выходит - тоже автоматизированную напоминалку куда-нибудь вкрутить. А то могут и забыть - их все раздергивают.  А может быть и так, что мне ответят: "Мы никакого гофратора для Луганска не везем"..... Потом выясняется, что это калибратор, но пока это выяснится со мной будет два микроинсульта.

4. Вы сказали, что над заявками работают 32 человека - это включая сотрудников отдела закупки или только те, кто непосредственно работает с клиентом, условно "продажники"? Если продажники - то получается 150 заявок/ 32 человека = примерно 5 заявок в день. Или тут другая арифметика?

Это только продажники. Но заявки сложные, и они не только с заявками работают: Клиентов уговаривают/дожимают. Чтобы столько заявок пришло, сколько надо отработать пустых контактов и т.д. Но, конечно, людей там больше, чем надо. Причины отчасти описаны выше.

Доброго здоровья,

2010-08-18 22:54:03
Дмитрий Гончаренко » Анна Буздыкина

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


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


А что, кстати, руководство? Видит проблемы? Предпринимает какие-то шаги, чтобы что-то изменить?

2010-08-19 09:12:19
Анна Буздыкина » Дмитрий Гончаренко

Дмитрий,

это не ответ на вопрос:

 

"Все поступающие данные должны быть в одном стандарте (чтобы их обработать ОК), но они не могут быть в одном стандарте - т.к., они входящие и создаются всегда не нами по определению (т.е., создаются "окружающей средой", которую мы изменить не можем)". Как быть?

 

Это уход от ответа по типовой цепочке:

  • 1. Давайте подумаем вместе - Ура!
  • 2. Я не буду лезть с преждевременными советами - Наверное "свалит"
  • 3. Чтобы решить эту задачу надо
    • сделать ревизию бизнес-процессов - типовой уход от задачи "через надсистему", как тут жаргонят, (окружающая среда не доросла до нас ментально). Но я пояснила, что все указанные вторичные задачи, описанные мной выше и не только, являются следствием нерешенности одной ключевой, которуя я в этом топике подчеркнула.
    • внедрить полноценную автоматизированную систему - а мы о чем беседуем? - мы беседуем об одном узком месте. Представьте, у нас есть и воля, и деньги, и даже CRM :-) Ну, и знания кое-какие... Но я не считаю, что "полноценная автоматизированная система" решает эту задачу - т.к., автоматизированная система работает с данными, которые в нее уже введены. А у нас задача по вводу данных
    • о чем думает Ваше руководство - похоже на типовой уход через риторический вопрос. Руководство наше думает над подчеркнутой задачей.

У меня есть только след. направления решения:

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

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

 

б) Ваш намек: "Все равно Вы сами думаете и вбиваете. Так будет продолжаться. Постарайтесь не ошибаться при анализе ситуации, отождествлении номенклатурной позиции и вводе данных".

 

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

 

в) Сможете продолжить список?

 

Доброго здоровья,

2010-08-19 11:26:01
Дмитрий Гончаренко » Анна Буздыкина

Анна,

это не ответ на вопрос... Это уход от ответа по типовой цепочке...

Честно говоря, в этом топике я пытаюсь найти ответы на другой вопрос - он вынесен в первое сообщение этой ветки. Но я человек мягкий, поэтому готов поиграть в "вопросы здесь задаю я" - в смысле, Вы :)

типовой уход от задачи "через надсистему"

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

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

в) Сможете продолжить список?

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

2010-08-20 20:01:32
Анна Буздыкина » Дмитрий Гончаренко

Список-то можете продолжить?

Доброго здоровья,

2010-08-21 22:25:46
Дмитрий Гончаренко » Анна Буздыкина

Теперь я уже должен жениться. Как честный человек. © Остап Бендер


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


Но так как я сам предложил воспользоваться типовыми приемами решения противоречий, видимо мне и прийдется это делать :)


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


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

2010-08-21 22:26:59
Дмитрий Гончаренко » Всем

ПРИЕМ 1
ПРИНЦИП ДРОБЛЕНИЯ
а) Разделить объект на независимые части.
б) Выполнить объект разборным.
в) Увеличить степень дробления объекта.

Нового решения прием мне не дал, выводит на предложенный раньше вариант: разделить заявку на «легкие, понятные» и «сложные, требующие проработки» строки. Легкие вносятся в систему и отрабатываются стандартным образом, сложные прорабатываются отдельно с отделом закупки, утверждаются с клиентом и потом добавляются в систему.

2010-08-21 22:27:40
Дмитрий Гончаренко » Всем

ПРИЕМ 2
ПРИНЦИП ВЫНЕСЕНИЯ
Отделить от объекта "мешающую" часть ("мешающее" свойство) или, наоборот, выделить единственно нужную часть (нужное свойство).

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

2010-08-21 22:29:08
Дмитрий Гончаренко » Всем

ПРИЕМ 3
ПРИНЦИП МЕСТНОГО КАЧЕСТВА
а) Перейти от одной структуры объекта (или внешней среды, внешнего воздействия) к неоднородной.
б) Разные части объекта должны иметь (выполнять) различные функции.
в) Каждая часть объекта должна находиться в условиях, наиболее благоприятных для ее работы.

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

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

2010-08-21 22:29:56
Дмитрий Гончаренко » Всем

ПРИЕМ 6
ПРИНЦИП УНИВЕРСАЛЬНОСТИ
Объект выполняет несколько разных функций, благодаря чему отпадает необходимость в других объектах.

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

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

2010-08-21 22:30:41
Дмитрий Гончаренко » Всем

ПРИЕМ 7
ПРИНЦИП "МАТРЕШКИ"
а) Один объект размещен внутри другого объекта, который, в свою очередь, находится внутри третьего и т. д.;
б) Один объект проходит сквозь полость в другом объекте.

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

Вторая мысль по этому приему:
Поместить заявку в нечто более крупное, «большую матрешку»:
•    Стандартное решение для бизнеса клиента
•    Месячный набор повторяющихся покупок (расходники)
•    и т.п.

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

2010-08-21 22:31:22
Дмитрий Гончаренко » Всем

ПРИЕМ 9
ПРИНЦИП ПРЕДВАРИТЕЛЬНОГО НАПРЯЖЕНИЯ
Заранее придать объекту напряжения, противоположные недопустимым или нежелательным рабочим напряжениям.


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

Мысль №2 по этому приему:
Обещать дополнительную скидку (подарок, бесплатную доставку, другой бонус) клиентам в случае заполнения заявки удобным для нас способом.

2010-08-21 22:32:01
Дмитрий Гончаренко » Всем

ПРИЕМ 10
ПРИНЦИП ПРЕДВАРИТЕЛЬНОГО ИСПОЛНЕНИЯ
а) Заранее выполнить требуемое изменение объекта (полностью или хотя бы частично).
б) Заранее расставить объекты так, чтобы они могли вступить в действие с наиболее удобного места и без затрат времени на доставку.

Мысль №1: Опять пересечения с удобной формой заявки (пункт а) и использованием кода, оптимизированного для быстрого ввода оператором в систему (пункт б).

Мысль №2: Опять пересечение с мыслью про заранее подготовленную типовую/прогнозируемую заявку клиента.

Мысль №3: Заранее выполненная заявка, «заявка без заявки».
«В прошлом месяце Вы купили у нас Оборудование А, обычно после начала работы наши клиенты обращаются к нам за Оборудованием Б, которое помогает эффективнее использовать Оборудование А. У нас как раз новое поступление этого оборудования, если Вы заинтересуетесь, мы могли бы отправить его Вам завтра в первой половине дня.»

2010-08-21 22:32:29
Дмитрий Гончаренко » Всем

ПРИЕМ 11
ПРИНЦИП "ЗАРАНЕЕ ПОДЛОЖЕННОЙ ПОДУШКИ"
Компенсировать относительно невысокую надежность объекта заранее подготовленными аварийными средствами.

Хорошо ложится на использование автоматических средств распознавания и ввода заявки – можно «зашить» в код и наименование товара некие контрольные суммы, которые автоматика сверяет, чтобы случайно не наводить в систему ошибочно распознанных данных. Если в системе есть такая защита и средства распознавания, ей можно скармливать все, кроме «почеркушек».

2010-08-21 22:33:03
Дмитрий Гончаренко » Всем

ПРИЕМ 14
ПРИНЦИП СФЕРОИДАЛЬНОСТИ
а) Перейти от прямолинейных частей объекта к криволинейным, от плоских поверхностей к сферическим, от частей, выполненных в виде куба или параллелепипеда, к шаровым конструкциям.
б) Использовать ролики, шарики, спирали.
в) Перейти к вращательному движению, использовать центробежную силу.

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

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

2010-08-21 22:33:38
Дмитрий Гончаренко » Всем

ПРИЕМ 16
ПРИНЦИП ЧАСТИЧНОГО ИЛИ ИЗБЫТОЧНОГО РЕШЕНИЯ
Если трудно получить 100% требуемого эффекта, надо получить "чуть меньше" или "чуть больше". Задача при этом может существенно упроститься.

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

2010-08-21 22:34:23
Дмитрий Гончаренко » Всем

ПРИЕМ 17
ПРИНЦИП ПЕРЕХОДА В ДРУГОЕ ИЗМЕРЕНИЕ
а) Трудности, связанные с движением (или размещением) объекта по линии, устраняются, если объект приобретает возможность перемещаться в двух измерениях (то есть на плоскости). Соответственно, задачи, связанные с движением (или размещением) объектов в одной плоскости, устраняются при переходе к пространству трех измерений.
б) Многоэтажная компоновка объектов вместо одноэтажной.
в) Наклонить объект или положить его "набок".
г) Использовать обратную сторону данной площади.
д) Использовать оптические потоки, падающие на соседнюю площадь или на обратную сторону имеющейся площади.

Пофантазируем?
Пусть заявки будут не плоскими, а объемными – например, в виде картонных моделей предлагаемого нами оборудования. В модельках конструктивно задана сопрягаемость/совместимость, клиент может «поиграть» с ними и составить решение для себя.


К нашей задаче это решение в общем-то притянуто за уши – но в качестве интересного сувенира идею запомнить можно. Также, возможно, с помощью такого «объемного» прайс-листа решается задача ознакомления и выбора нового для клиента оборудования, которое он затрудняется даже правильно назвать (пример с гофратором/калибратором из нашего обсуждения)

2010-08-21 22:36:07
Дмитрий Гончаренко » Всем

ПРИЕМ 19
ПРИНЦИП ПЕРИОДИЧЕСКОГО ДЕЙСТВИЯ
а) Перейти от непрерывного действия к периодическому (импульсному).
б) Если действие уже осуществляется периодически - изменить периодичность.
в) Использовать паузы между импульсами для другого действия.


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


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


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


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

2010-08-21 22:36:48
Дмитрий Гончаренко » Всем

ПРИЕМ 22
ПРИНЦИП "ОБРАТИТЬ ВРЕД В ПОЛЬЗУ"
а) Использовать вредные факторы (в частности, вредное воздействие среды) для получения положительного эффекта.
б) Устранить вредный фактор за счет сложения с другим вредным фактором.
в) Усилить вредный фактор до такой степени, чтобы он перестал быть вредным.


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


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


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

2010-08-21 22:37:14
Дмитрий Гончаренко » Всем

ПРИЕМ 23
ПРИНЦИП ОБРАТНОЙ СВЯЗИ
а) Ввести обратную связь.
б) Если обратная часть есть - изменить ее.


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

2010-08-21 22:38:07
Дмитрий Гончаренко » Всем

ПРИЕM 24
ПРИНЦИП "ПОСРЕДНИКА"
Использовать промежуточный объект-переносчик.


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


Мысль №2: Диктофон для записи телефонных переговоров с клиентом – так не забудется важная информация и можно будет вернуться к записи в случае разбора полетов.


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

2010-08-21 22:42:47
Дмитрий Гончаренко » Всем

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


Если у Вас будет желание - продолжим вместе.

2010-08-22 15:20:29
Владимир Ситников » Дмитрий Гончаренко

Браво Дмитрий!

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


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

Пока лучшее решение: волны + документы гугла. Но волны планируют закрывать, ищу альтернативу...

2010-08-22 16:00:21
Дмитрий Гончаренко » Владимир Ситников

Спасибо, Владимир!

Отослал ссылку почтой.

2010-08-22 17:58:36
Михаил Опанасенко » Дмитрий Гончаренко

Добрый день!

Мне тоже пришлите. Однако решения Ваши разберу (ключевая задача, мне кажется, не решена).

 

В любом случае, присоединяюсь к похвалам тем, кто не только спрашивает, но и думает. Добро пожаловать.

С Уважением,

2010-08-22 22:54:02
Дмитрий Гончаренко » Михаил Опанасенко

Мне тоже пришлите

Выслал


Однако решения Ваши разберу (ключевая задача, мне кажется, не решена).

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

2010-08-23 06:05:35
Анна Каправчук » Дмитрий Гончаренко

Уважаемый Дмитрий!

1. Аплодирую Вашей методичности в решении задачи Анны Буздыкиной.

2. И мне ссылочку, пожалуйста. Если можно - то на тот продукт, который Вы намерены предлагать фрилансерам.

С уважением,

Анна Каправчук

2010-08-23 08:45:19
Дмитрий Гончаренко » Анна Каправчук

Отослал ссылку. Спасибо за проявленный интерес :)


2010-08-23 08:52:14
Редакция » Всем

Уважаемые Коллеги!

Программу Дмитрия просьба разбирать в этой ветке.

Задачу Анны здесь.

Спасибо,

2010-08-23 15:39:02
Михаил Опанасенко » Всем

Уважаемый Дмитрий, уважаемая Анна!

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

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

ТРИЗ требует обострения противоречия, а не сглаживания его. Поэтому я предлагаю формулировку: "Данные всегда приходят не в том виде" и разрулить это невозможно по условиям задачи. Тогда ИКР в моем понимании такой: "Идеально, если данные всегда приходят в разном виде, но это нам никак не мешает. Мы легко работаем с разнородными данными также, как и с однородными".

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

Успеха,

P.S. Дмитрий, о Вашей программе напишу в другой ветке.

2010-08-23 16:10:53
Дмитрий Гончаренко » Михаил Опанасенко

"Идеально, если данные всегда приходят в разном виде, но это нам никак не мешает. Мы легко работаем с разнородными данными также, как и с однородными"


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

2010-08-23 17:10:06
Анна Буздыкина » Всем

Я тоже не против идеала, указанного Михаилом.

Доброго здоровья,

2010-08-23 17:27:36
Михаил Опанасенко » Всем

Уважаемые Коллеги!

Тогда становится видно, что из всегт списка, предложенного Дмитрием, сходу не отпадают только...

 

  • матрешечные решения с индексом/кодом товара (но мне, все же, кажется, что они реализуемы только, если Клиент таки создал заявку через нашу систему)
  • и совершенно дикое направление про антиавтоматизацию. (Но АРИЗ нам советует идти в диком направлении. Пойдем что-ли?)
  • Но их объединение наводит меня на какие-то прозрения... Я пока сделаю паузу... поформулирую.

    Успехов,

    P.S. Мне также (независимо от основной задачи) понравились решения с объемной сувениркой, "форвардном" участии в будущей закупке, а также решение, про то, что "Вы покупали у нас прошлый раз, а вот как оно еще комплектуется..." (почти "мультисекция"). К тому же, я знаю, как это реализовать (на том же Оффербуке смогу сделать)...  Но эти ветки я развивать пока не хочу, несмотря на их забористость, т.к. они не решают основную задачу (хотя другие задачи вполне решают).

    2010-08-25 19:38:27
    Михаил Опаснасенко » Всем

    Уважаемые Коллеги!

    Продолжаю обострять тему "антиавтоматизации".

    Цитирую Дмитрия Гончаренко:

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

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

    Плохо то, что при работе с потоком таких заявок мы не сможем их администрировать:

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

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

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

    1. Т.о., голос с телефона, графический или pdf-файл неважно  с чем и/или файл иного формата, все это может быть собрано в одно комплексное сообщение, которое в таком вот виде и зафиксируется на "контрольной ленте всех заявок" (так назовем). [Наверняка можно использовать и иные программы и средства, а не только перечисленные программы, я их привел, чтобы проиллюстрировать о чем речь].

    2. Каждый "продажник" таким образом общается с Клиентом как ему удобно (только факсы надо принимать в компьютер, а не в факс-аппарат = соответствующих программ много = тогда и факсы будут графическими файлами). Но - при этом - его "почеркушко-разговор" попадает на "контрольную ленту всех заявок". А поскольку он зашел в свой комп под своей учетной записью, то "почеркушко-разговор" зафиксирует: кто его "произвел". Зафиксируются также дата, время создания и проч. необходимые атрибуты.

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

    4. Каждая заявка всегда фиксируется на "контрольной ленте", но также она отображается по иным потребным лентам. Например, Анна Буздыкина поговорила по телефону про "луганский гофратор" + получила факс в компьютер. Все это попало на контрольную ленту, но также отобразилось (со всеми атрибутами) на ленту "Продажник Анна Буздыкина".

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

    6. У поставки появляется электронная очередь заявок. Собственно, у всех появляются эти очереди и все прозрачно фиксируется. И надо помнить, что у всех есть контрольное время на обработку. Т.о., мы можем все мониторить. В назначенное время Гоша впишет в заявку: "Анна, это калибратор "Стальные обрезки ГОСТ 99999999-01" у нас в базе его ID 6565656. Прочти описание и уточни у Клиента - этот ли". И ставит "крыжик на Анну". (А контрольная-то лента все видит и сроки тоже и отчеты формируются по текущей работе).

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

    8. Дальше, как мне кажется, все ясно. Картина прозрачна, диспетчер курит бамбук и готовится к сокращению, а подбор собственно позиций из базы и формирование "итоговой правильной заявки Клиента" происходит на последней стадии, когда уже все ясно о чем речь и не составит труда ее сформировать. Ну, или на первой, когда Анне все ясно сразу.

    Что скажете?

     

    Успехов,

    2010-08-26 09:06:03
    Дмитрий Гончаренко » Михаил Опаснасенко

    Интересно, что ответит Анна - задачедатель она, ей и судить о применимости такого подхода.


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


    Из отличий:

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

    Чего у нас нет: прямой завязки сроков выполнения с системой ЗП. Такая возможность появится после реализации запланированного функционала.

    2010-08-26 22:24:29
    Анна Каправчук » Михаил Опанасенко

    Читала фрагменты-описания стандартных "грабель" из "Записки автоматизатора. Профессиональная исповедь"  Орлова вот здесь:

    http://www.boffobooks.ru/book.html?id=12034&rfr=24385 

    и сразу очень живо вспомнила  эту задачу...

    2010-08-27 09:23:37
    Анна Буздыкина » Всем

    Я "чешу репу".

    Доброго здоровья,

    P.S. Я этим "Эвернотом" даже пользовалась какое-то время ("визитки организовывала") ......

    2010-08-27 10:09:43
    Михаил Опанасенко » Дмитрий Гончаренко

    Добрый день!

    Если у Вас не будет "контрольной ленты", боюсь, у Вас будет вот так.

    нет аналога "контрольной ленты всех заявок" - для текущей работы на мой взгляд она не имеет смысла, ведь каждый работает со своими заявками.

    Если.

    При этом контрольные функции Администратор может осуществлять, просматривая "контрольные ленты" в разрезе Сотрудника, Клиента, Проекта или Задачи.

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

    Аналогия: бухгалтер может смотреть оборотно-сальдовую ведомость в разрезе любого счета или субсчета, а также вносить данные в разных контекстах, но "главная книга" ведется автоматически.

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

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

    С Уважением,

    2010-08-27 11:20:46
    Дмитрий Гончаренко » Михаил Опанасенко

    Наверное мы просто не до конца понимаем друг друга.

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

    2010-08-27 13:55:00
    Михаил Опанасенко » Дмитрий Гончаренко

    Смотреть - да.

    Т.е., в текущей работе можно смотреть куда удобно. Но контрольная лента нужна. Иногда удобно посмотреть именно на нее.

     

    С Уважением,

    2010-08-27 14:29:49
    Дмитрий Гончаренко » Михаил Опанасенко

    Согласен.



    Яндекс.Метрика