Windows Система обработки заявок

[Andi]

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

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

Современные веяния - это использование распределённых вычислительных систем и WEB интерфейсов. Таким образом, SPult мог бы сформировать, например, HTML POST запрос с телом в виде XML строки, содержащей параметры заявки и получить какой-то ответ о статусе этой заявки. Этот запрос может быть передан от SPult в систему обработки заявок по протоколу http или https. В настройках SPult носится URL (возможно с портом), куда и отправляется запрос. На этом функции SPult, в части работы с заявками, заканчиваются.

Вся дальнейшая работа с введённой заявкой производится уже в системе обработки заявок, имеющей, например, WEB интерфейс.

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

 

[revit]

Не совсем понимаю о какой заявке формируемой в СПульт идет речь? Система ОБЬ и программа Спульт в частности используется для контроля, получения данных с лифтов и осуществления ГГС и информация полученная из нее анализируется сначала персоналом (диспечтером) и только после анализа принимается решение оформлять завку или нет. ИМХО нельзя однозначно интерпретировать данные полученные с лифтов .

 

[sergey57949]

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

 

[revit]

Но тогда нужна синхронизация базы адресов Спульт и программы обработки заявок т.к. вбивают адреса лифтов и идентификаторы их местоположения кому как понравится в разных программах. У нас допустим это самодельная прога на базе MySQL и там своя база адресов и бывают накладки и несовпадения с адресами в Спульт. В планах реализовать ее на базе платформы 1С

 

[Andi]

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

Действительно, диспетчер в SPult формирует саму заявку на ремонт лифта. Как уже писал, SPult передаёт заявку другой системе - системе контроля обработки заявки, которая уже дальше ведёт контроль исполнения этой заявки. Хорошо бы, что бы система обработки заявки имела WEB интерфейс и механики дописывали со смартфонов и компьютеров любого типа в браузере (не в ASPult) свои действия.

 

[sergey57949]

Идея хороша.
Но я за то чтобы прога исходила от ЛКДС.
Не то чтоб им не чем занятся, просто я за единообразие.

 

[Andi]

Но тогда нужна синхронизация базы адресов Спульт и программы обработки заявок т.к. вбивают адреса лифтов и идентификаторы их местоположения кому как понравится в разных программах. У нас допустим это самодельная прога на базе MySQL и там своя база адресов и бывают накладки и несовпадения с адресами в Спульт. В планах реализовать ее на базе платформы 1С

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

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

 

[revit]

... Хорошо бы, что бы система обработки заявки имела WEB интерфейс и механики дописывали со смартфонов и компьютеров любого типа в браузере (не в ASPult) свои действия.

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

 

[Kranch]

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

Можно сделать, что бы механик мог поставить промежуточный статус заявки "Выполнено", но закрывает окончательно диспетчер. А вот диспетчеру нужно будет дополнительно её открыть, проверить по Spult и если все нормально закрыть, если нет, то пустить обратно в работу.

 

[sergey57949]

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

 

[Andi]

Идея хороша.
Но я за то чтобы прога исходила от ЛКДС.
Не то чтоб им не чем занятся, просто я за единообразие.

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

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

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

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

 

[Kranch]

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

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

Если говорить про набор параметров, то тут надо смотреть какие параметры требуется в сторонней системе, и какие можно выбирать. А если в общем, то передавать нужно ID(вся синхронизация привязана к данному параметру, так как все остальные параметры могут изменяться), Адрес, Справочные параметры(по которым в системе формируется список персонала кому можно передать заявку), можно ввести настраиваемый пункт"Передавать дополнительную информацию" если выбран, то дополнительно в теле Описания заявки приписывается информация, которая указана в панели управления лифтом на момент нажатия кнопки создать заявку(типа: +Аварийная блокировка +43 Неисправна цепь блокировок)

 

[StAlex]

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

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

 

[revit]

Хотя поля заявки я бы сделал настраиваемыми - требования у разных организаций разные.

И сколько таких организаций? И скольок различных программ? И вообще как совместить несовместимое?

 

[sergey57949]

Вот поэтому я за то, чтоб была прога от ЛКДС.
Насчет требований тоже не вижу предмета спора.
Дата, время, адрес и причина остановки берется с Спульта, остается добавить время устранения и причину вызвавшую остановку и ФИО устранившего.
Это базовые поля.
А вот дальше желательно бы иметь возможность добавлять поля, хотя вышеперечисленные поля меня вполне устраивают, но тут уж все от разработчиков зависит

 

[revit]

Может я чего не догоняю.... Как эти поля потом засунуть в нашу прогу? А у каждого своя....

 

[Andi]

Может я чего не догоняю.... Как эти поля потом засунуть в нашу прогу? А у каждого своя....

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

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

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

 

[vmiheev]

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

 

[Pro100A1ex]

Вот поэтому я за то, чтоб была прога от ЛКДС.

Поддерживаю, за это решение отдельно и заплатить даже можно

Может я чего не догоняю.... Как эти поля потом засунуть в нашу прогу? А у каждого своя....

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

 

[sergey57949]

Pro100A1ex, эй полегче, не спугни.
Пусчай журнал сделают, gps потом просить будем

Поддерживаю, за это решение отдельно и заплатить даже можно

Куда деньги переводить?