Решая вопросы управления компанией регулярно приходилось сталкиваться со следующей проблемой -

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

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

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

Я рассматривал различные методы построения такого генератора событий -

1. Напоминания в MS Outlook. Неудобно. Напоминания генерируются индивидуально каждому сотруднику. Нужно индивидуально настраивать Outlook. Можно, конечно, поиграть групповыми задачами или приглашениями, но есть второе неудобство.  Собственно напоминания. С учетом того, что в нашей компании основной инструмент управления - электронная почта - напоминания оказались неудобны. Не возможно - читай почту, следи за напоминаниями, да не забудь еще сходить в Twitter  и в Skype.

Я все же остановился на решении - рассылать такие напоминания как почтовые сообщения. Тогда что?

2. Можно рассылать напоминания из 1С. С учетом того, что управленческая система построена на базе 1С, и 1С умеет рассылать сообщения, мы попытались реализовать эту схему. Не удобно. Необходимо, чтобы 1С была запущена хотя бы у одного сотрудника. 1С не запущена - сообщения не генерируются.

3. Как вариант рассматривали Sharepoint Server в комбинации с общими папками Outlook. На столько сложно, что не воркабельно.

4. Я рассматривал вариант приобретения специального софта.  За 700 рублей можно приобрести набор утилит для Outlook от MAPI Lab. Там есть что-то похожее. Уже рука тянулась оплатить эту историю.

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

- не привязано к запуску какой либо программы - 1С, Outlook - единственным условием работы является включенный сервер.

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

Единственное ограничение - наличие внутреннего SMTP сервера. У нас этот сервер имеется. У многих он тоже есть. к тому же SMTP Server является компонентой Windows Server и может быть установлен вместе с установкой серверной операционной системы.

Э.В.Костюк.  Руководитель компании. 

Scheuler e-mail | почта | расписание | SMTP | почтовый сервер | бизнес процедуры

По следам одного из проектов......

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

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

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

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

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

Сценарий 1.

У нас есть головной офис, а так же несколько площадок, на которых работает от одного до трех сотрудников. Эти сотрудники работают с некой информационной системой (например 1С торговля), читают электронную почту, а так же работают с документами Word,  Excel.

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

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

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

С позиции руководителя мне бы хотелось централизовать всю информацию в головном офисе и не выпускать ее за пределы периметра. Поэтому первые три минуса для меня существенные.

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

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

Сценарий 2.

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

Другими словами - удаленная площадка использует ресурсы головного офиса, а головной офис регулярно использует ресурсы удаленной площадки.

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

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

Сценарий 3.

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

Другими словами - удаленной площадки нет как таковой. Есть удаленные сотрудники, которые используют ресурсы головного офиса, и при этом могут это делать из совершенно произвольных мест.

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

Но прежде чем это делать необходимо ответить на два вопроса

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

2. Если перечень закрытый, есть ли возможность предоставить доступ к этим ресурсам через WEB интерфейс?

Например, если сотруднику нужна почта - можно применить сервер, позволяющий подключение к нему через WEB интерфейс.  Если это 1С торговля - можно использовать последние версии 1С, имеющие WEB интерфейс. Если это файлы Word и Excel, можно использовать SharePoint.  В этом случае вообще снимается вопрос с применением каких то специальных средств для подключения к головному офису удаленных сотрудников. А так же достигается определенная универсальность, так как работать с WEB интерфейсом можно даже со смартфона.

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

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

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

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

Э.В.Костюк.  Руководитель компании.

каналы связи | удаленные площадки | Объединение офисов | VPN

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

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

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

- заявки на восстановление

- заявки на обслуживание

- заявки на изменение

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

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

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

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

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

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

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

- Заявка на обслуживание  - это консультация на техподдержке. Или плановые задачи для линейного сотрудника.

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

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

1. Функциональное разделение сотрудников, с выделением службы техподдержки, линейных специалистов, администраторов. Но этого не достаточно. Само по себе такое разделение вызывает неразбериху в работе и перекладывание ответственности.

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

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

Над этим сейчас работает менеджмент компании.

Э.В.Костюк  Руководитель компании.

Обслуживание компьютеров | ITIL | заявка на обслуживание