Полностью согласен! Верхушка руководства вообще не грузится такими задачами как кол-во тикетов и даже просрочек по ним в ИТ подразделении, пока в целом все ок.
Как правило их больше заботит расширение бизнеса, поглощения и т.п., ИТ для них что-то вроде компьютера без которого нынче никак не обойтись. Увы.
В большинстве случаев тикеты заводить вполне можно автоматически — либо по связке CallerID = клиент/сотрудник либо JabberID = клиент/сотрудник либо с email либо sms и т.д.
Было бы желание автоматизировать, затратив время и силы на начальном этапе, в дальнейшем нагрузка будет падать.
Возмите за пример работу саппорта в телекомах и сотовой связи — звонит клиент — сразу открывается его карточка со всеми данными. Спецу поддержки только свой ремарк внести или из шаблона выбрать и тикет уже готов и оформлен со всей нужной атрибутикой.
Небольшой практический максимально дешевый, но рабочий пример реализации как составная часть описанного мною ранее на Хабре корпоративного портала. На панацею не претендую, но быть может комуто проще будет решить задачу аналогично.
Необходимые условия:
1. Вебсервер(к примеру LAMP) с базой сотрудников/клиентов
2. Jabber(XMPP) сервер (какой именно не особо важно).
Подготовительная работа:
1. На Jabber заводим учетку для бота для взаимодействия с клиентами или сотрудниками.
2. На вебсервере составляем классификатор ключевых слов(тегов) с названиями категорий и перечнем JabberID ответственных сотрудников.
Схема работы следующая:
1. Сотрудник или клиент пишет боту сообщение вида «ТЕГ Не работает.....»
2. Скрипт на стороне сервера получает сообщение, обрабатывает тег, сохраняет обращение в базу и отсылает закрепленным исполнителям уведомление о проблеме 1 к 1.
3. Техперсонал получает уведомление со ссылкой на вебстраницу, ознакамливается с проблемой, решает ее, пишет ответ тамже.
4. Заявитель(сотрудник или клиент) получает уведомление что либо его задача принята(например картридж выписан) либо что проблема решена.
В итоге получаем базу с типовыми проблемами и систему оперативного уведомления и прочую пищу для размышлений: что, как часто, у кого, кто решал проблему и т.п.
Затраты на внедрение: закупка железа(уже есть по условиям), закупка ПО — 0р, время на разработку 1 неделя, на багтестинг еще 1 неделя на 1-2 сотрудников.
В дополнение сказанному beho1der еще стоит отметить и финансовый аспект:
1. Нужно потратиться на готовую систему, для которой с сотнями сотрудников очень нехилая сумма выходит.
2. Нужно ежемесячно отстегивать разрабам за техсаппорт ибо сами разобраться в их деянии и тем более адаптировать под месные особенности не представляется возможным из-за больших временных затрат, а при этом еще надо выполнять и рутину, которую никто не отменял.
Итого считаю необходимость покупки сторонних ИС оправданной только при внедрении с 0 и как правило крупного ПО по работе с финансовыми потоками. В данной же статье идет речь преимущественно о работе с пер.данными сотрудников строго внутри организации.
Просто пример:
Microsoft Windows Server CAL 2008. Цена: от 970.00 руб. www.softkey.ru/catalog/program.php?sphid=38705422&ID=37371 CAL — это не программный продукт, это — лицензия, которая дает пользователю право на доступ к услугам сервера.
Первейшая мера — физическое отсутствие публичного доступа из Интернет(да и доменное имя .local).
Сетевая безопасность вне моей компетенции, но тем не менее все каналы связи межофисные — OpenVPN или IPSec. Отдел ИТ безопасности тоже имеется.
Программная защита — исключение передачи пароля в открытом виде, только случайные хеши привязанные к сеансу. Под давлением сверху для забывчивых паролей пришлось сделать куки авторизацию, но опять же хеши, привязанные в т.ч. к IP в локальной сети, подмена IP блокируется сисадминами. Локально в куках или еще как не хранится ничего связанного с группами доступа.
Однако общеизвестный факт, что самое слабое место любой системы — это ее пользователи. Тут я практически бессилен, разумеется кроме ограничений на простоту пароля и периодических разъяснительных работ о том как важно свой пароль все же запоминать, а не записывать.
Недавно на Хабре проскочила полезная имхо статья про passwordcard, пробую оттестировать данный подход на особо забывчивых.
Спасибо за пожелание, при случае обязательно, но вопрос создания отдельного подразделения вызывает также вопрос о расширении штата ибо уже имеющиеся в наличии сотрудники по умолчанию уже заняты на 100%, что соответственно вызывает не позитивную реакцию изначально.
Позиция ясна. Да, бесспорно дополнительный груз сопровождения имеется, тут вы правы, но как-то сложилось, что и глюков мало было за 4 года и при малейшем их проявлении вызывали и допрашивали лично меня, а не непосредственного. А к тому же уж звиняйте судьба такая у руководителей — отвечать за все проекты в их подразделении(а их десятки и +-1 не решает) за это им и зп выше, ее тоже надо отрабатывать и думать не только о своих интересах(работы бы поменьше, а зп повыше) но и вцелом рутину в конторе исключить по максимуму, тоже ведь наемные работники.
Далее, лично моя нагрузка особенно в момент первичного развертывания была явно выше средней и было очень нелегко, но я решил «день потерять, затем за 5 минут долететь» несмотря на то что было очень и очень непросто соблюдать и основные сроки и дорабатывать инициативную часть дабы не опозориться на первом демопоказе. И как показало время — данный подход себя оправдал, я сделал все возможное, чтобы каждый источник информации и ее потребитель зависел от меня минимально(даже если я вообще уволюсь). Мое вмешательство требуется только для оптимизации невидимую простому пользователю + разработку новых модулей либо по просьбам большинства сотрудников(уменьшение рутины) либо по приказу свыше. При этом ни один срок по первичным задачам не был сорван.
Мой отдел изначально назывался «отдел автоматизации» и по сей день так называется. Как водится в крупных конторах главное руководство занимается внешнеполитическими делами и крайне труднодоступно, но в тоже время в результате многомесячного упорства достучаться всеж порой получается, в частности подписать приказ и последующие распоряжения о разграничении сфер ответственности за внесенную в портал информацию уже удалось, пусть не на 100%, но работа ведется постоянно и в этом направлении тоже.
С таким подходом тоже сталкивался, бесспорно тут есть свои очевидные плюсы, вы правы. Но все меркнет при первой же маломальски серьезной проблемой, когда нужно решить вопрос немедленно, а тебе в трубку «подождите, вы N-ый в очереди на обслуживание» или просто игнор на запросы к разрабам по email.
Непрофильная — это когда рабочее время тратят на личные проекты и служебным Интернетом в личных целях — заказы, закупки, баш и т.п. А насчет развития данного проекта у меня в должностных явно прописано «принимать все возможные меры по автоматизации труда» и будучи веб-разработчиком я именно это и сделал. И есть простая истина — если бы сверху посчитали бы это непрофильным — никто никогда официально не утвердил данный проект.
Целый цикл статей был на Хабре, что от молчаливо плывущих по течению сотрудников выполняющие работы только по приказу, толку для организации минимум, а порой и вред ибо зп надо выплачивать регулярно независимо от факта наличия/отсутствия ежедневных указаний чего сегодня сделать нужно.
Развертывание моего проекта обошлось компании всего в ~30 килоруб. только на железо сервера в стойку. ЗП за новую обязанность никто не прибавлял. В чем же вред по-вашему для фирмы в целом?
По моему вы саму статью невнимательно прочли. Все развивалось как добавление фич в систему по прямым обязанностям, а после приказа это вообще перестало быть лишь инициативой и стало очередной официальной обязанностью. Отношение руководства неоднозначно: непосредственное приревновало, высшее выразило благодарность, вот так.
Ваше мнение видимо в том, что стоило на все это забить на всю эту автоматизацию, уменьшение рутины не только своей, но и коллег и спокойно «пить чай/кофе» в минутки свободного времени от основных обязанностей? Или я ошибаюсь?
Моменты в архитектуре, порядок внедрения и т.п., а не курс программирования на PHP и MySQL. Почитайте другие комментарии и вопросы которые задают хабровчане. Халяву здесь не раздают однако, только обмен опытом.
Как правило их больше заботит расширение бизнеса, поглощения и т.п., ИТ для них что-то вроде компьютера без которого нынче никак не обойтись. Увы.
Было бы желание автоматизировать, затратив время и силы на начальном этапе, в дальнейшем нагрузка будет падать.
Возмите за пример работу саппорта в телекомах и сотовой связи — звонит клиент — сразу открывается его карточка со всеми данными. Спецу поддержки только свой ремарк внести или из шаблона выбрать и тикет уже готов и оформлен со всей нужной атрибутикой.
Необходимые условия:
1. Вебсервер(к примеру LAMP) с базой сотрудников/клиентов
2. Jabber(XMPP) сервер (какой именно не особо важно).
Подготовительная работа:
1. На Jabber заводим учетку для бота для взаимодействия с клиентами или сотрудниками.
2. На вебсервере составляем классификатор ключевых слов(тегов) с названиями категорий и перечнем JabberID ответственных сотрудников.
Схема работы следующая:
1. Сотрудник или клиент пишет боту сообщение вида «ТЕГ Не работает.....»
2. Скрипт на стороне сервера получает сообщение, обрабатывает тег, сохраняет обращение в базу и отсылает закрепленным исполнителям уведомление о проблеме 1 к 1.
3. Техперсонал получает уведомление со ссылкой на вебстраницу, ознакамливается с проблемой, решает ее, пишет ответ тамже.
4. Заявитель(сотрудник или клиент) получает уведомление что либо его задача принята(например картридж выписан) либо что проблема решена.
В итоге получаем базу с типовыми проблемами и систему оперативного уведомления и прочую пищу для размышлений: что, как часто, у кого, кто решал проблему и т.п.
Затраты на внедрение: закупка железа(уже есть по условиям), закупка ПО — 0р, время на разработку 1 неделя, на багтестинг еще 1 неделя на 1-2 сотрудников.
PS А что не так с комментариями?
1. Нужно потратиться на готовую систему, для которой с сотнями сотрудников очень нехилая сумма выходит.
2. Нужно ежемесячно отстегивать разрабам за техсаппорт ибо сами разобраться в их деянии и тем более адаптировать под месные особенности не представляется возможным из-за больших временных затрат, а при этом еще надо выполнять и рутину, которую никто не отменял.
Итого считаю необходимость покупки сторонних ИС оправданной только при внедрении с 0 и как правило крупного ПО по работе с финансовыми потоками. В данной же статье идет речь преимущественно о работе с пер.данными сотрудников строго внутри организации.
Microsoft Windows Server CAL 2008. Цена: от 970.00 руб.
www.softkey.ru/catalog/program.php?sphid=38705422&ID=37371
CAL — это не программный продукт, это — лицензия, которая дает пользователю право на доступ к услугам сервера.
Сетевая безопасность вне моей компетенции, но тем не менее все каналы связи межофисные — OpenVPN или IPSec. Отдел ИТ безопасности тоже имеется.
Программная защита — исключение передачи пароля в открытом виде, только случайные хеши привязанные к сеансу. Под давлением сверху для забывчивых паролей пришлось сделать куки авторизацию, но опять же хеши, привязанные в т.ч. к IP в локальной сети, подмена IP блокируется сисадминами. Локально в куках или еще как не хранится ничего связанного с группами доступа.
Однако общеизвестный факт, что самое слабое место любой системы — это ее пользователи. Тут я практически бессилен, разумеется кроме ограничений на простоту пароля и периодических разъяснительных работ о том как важно свой пароль все же запоминать, а не записывать.
Недавно на Хабре проскочила полезная имхо статья про passwordcard, пробую оттестировать данный подход на особо забывчивых.
Или же вопрос был к ncix?
Далее, лично моя нагрузка особенно в момент первичного развертывания была явно выше средней и было очень нелегко, но я решил «день потерять, затем за 5 минут долететь» несмотря на то что было очень и очень непросто соблюдать и основные сроки и дорабатывать инициативную часть дабы не опозориться на первом демопоказе. И как показало время — данный подход себя оправдал, я сделал все возможное, чтобы каждый источник информации и ее потребитель зависел от меня минимально(даже если я вообще уволюсь). Мое вмешательство требуется только для оптимизации невидимую простому пользователю + разработку новых модулей либо по просьбам большинства сотрудников(уменьшение рутины) либо по приказу свыше. При этом ни один срок по первичным задачам не был сорван.
Мой отдел изначально назывался «отдел автоматизации» и по сей день так называется. Как водится в крупных конторах главное руководство занимается внешнеполитическими делами и крайне труднодоступно, но в тоже время в результате многомесячного упорства достучаться всеж порой получается, в частности подписать приказ и последующие распоряжения о разграничении сфер ответственности за внесенную в портал информацию уже удалось, пусть не на 100%, но работа ведется постоянно и в этом направлении тоже.
Целый цикл статей был на Хабре, что от молчаливо плывущих по течению сотрудников выполняющие работы только по приказу, толку для организации минимум, а порой и вред ибо зп надо выплачивать регулярно независимо от факта наличия/отсутствия ежедневных указаний чего сегодня сделать нужно.
Развертывание моего проекта обошлось компании всего в ~30 килоруб. только на железо сервера в стойку. ЗП за новую обязанность никто не прибавлял. В чем же вред по-вашему для фирмы в целом?
Ваше мнение видимо в том, что стоило на все это забить на всю эту автоматизацию, уменьшение рутины не только своей, но и коллег и спокойно «пить чай/кофе» в минутки свободного времени от основных обязанностей? Или я ошибаюсь?