Корпоративный блог

  • Архив

    «   Ноябрь 2017   »
    Пн Вт Ср Чт Пт Сб Вс
        1 2 3 4 5
    6 7 8 9 10 11 12
    13 14 15 16 17 18 19
    20 21 22 23 24 25 26
    27 28 29 30      

В Йошкар-Оле регионы обсудили современные требования предоставления государственных и муниципальных услуг

14 июня в г. Йошкар-Оле состоялась конференция «Предоставление государственных и муниципальных услуг населению по принципу «одного окна»: современные требования и новые возможности», организованная совместно ФГУП «Почта России» и Правительством Республики Марий Эл при поддержке Компании БФТ.




В работе конференции приняли участие представители Почты России, Министерства экономического развития Российской Федерации, Совета Федерации Федерального Собрания РФ, ОАО «Универсальная электронная карта», а также более 90 представителей органов исполнительной власти из 40 субъектов РФ. 
Об опыте организации предоставления государственных и муниципальных услуг по принципу «одного окна» в Республике Марий Эл рассказал руководитель Департамента информатизации и связи Республики Марий Эл Венедикт СУВОРОВ. В настоящее время в регионе успешно функционируют 50 территориально-распределенных отделений МФЦ, созданных на базе отделений Почты России и действующих по принципу «одного окна». Информатизация процесса обслуживания граждан реализована на базе автоматизированной системы «МФЦ-Капелла»

Руководитель департамента подробно остановился на возможностях «МФЦ-Капелла»: «Использование системы при организации предоставления государственных и муниципальных услуг обеспечивает экспертную поддержку и контроль деятельности работников МФЦ по приему, выдаче, обработке документов, а также контроль исполнения сроков оказания услуг. Кроме того, в системе хранятся сведения об истории обращений заявителей, формируется статистическая отчетность по итогам деятельности многофункционального центра. 

Важно отметить, что система интегрирована с СМЭВ». В 2012 году в Республике Марий Эл было представлено 12 видов услуг, а по состоянию на 13 июня 2013 г. их перечень расширен до 28 видов. В течение 2013 года количество предоставляемых через МФЦ услуг населению планируется довести до 40. 



Теме комплексной автоматизации процесса предоставления государственных и муниципальных услуг с помощью системы «МФЦ-Капелла» было посвящено выступление Андрея НАЙЧЕНКО. 
Он также подчеркнул, что система не только автоматизирует основные процессы, но и оказывает экспертную поддержку – экспертная система в автоматическом режиме определяет возможность оказания услуги, список документов, необходимых для её оказания, и последовательность сбора недостающей информации в других органах власти. 

Андрей НАЙЧЕНКО особо рассмотрел так называемую «декомпозицию регламента», которая позволяет в системе «МФЦ-Капелла» даже непрофильным специалистам оказать качественную консультацию и прием соответствующих документов: 

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

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



В холле конференц-зала Антикризисного центра Республики Марий Эл, где проходила конференция, МФЦ Республики Марий Эл было представлено специализированное окно предоставления государственных и муниципальных услуг, которое полностью соответствовало специализированным окнам, созданным в Республике Марий Эл на базе ОПС. Каждый из участников мог получить консультацию у специалиста, а также доступ к порталу госуслуг или порталу МФЦ. 

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

Подробнее о конференции

Презентация ЦТО в Якутске

4 декабря состоялось открытие Регионального центра телефонного обслуживания (РЦТО) по информированию и консультированию физических и юридических лиц по вопросам предоставления государственных и муниципальных услуг. Подробнее. Видеорепортаж доступен по ссылке.

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

22-23 марта 2012 года состоялась ежегодная Международная конференция Министерства экономического развития РФ "Развитие государственного управления в России"."Капелла" с партнером компанией "БФТ" приняли участие в этом мероприятии.

Репортаж с конференции.

Капелла 4.0 – простое решение

Поговорим о создании полноценного решения на платформе Капелла 4.0.
Недавно стали доступны для публичного тестирования Windows 8 Consumer Preview и Visual Studio 11 Beta, поэтому не удивляйтесь, если на скриншотах вы увидите элементы их интерфейса smile:).

Создание решения в Visual Studio

Начнем с создания в Visual Studio пустого решения, которое назовем Capella4. Наше решение будет использовать Silverlight, поэтому будет состоять из двух основных проектов – веб-проекта Capella4.Web и собственно Silverlight-проекта – Capella4. Эти два проекта можно создавать разными способами, мы выберем один из них: выберем пункт меню Add New Project…, выберем Visual C# и Silverlight, а затем шаблон Silverlight Application. Укажем Capella4 в качестве названия проекта и нажмём ОК. Далее Visual Studio предложит нам создать веб-сайт, на котором будет размещено наше приложение. Т.к. мы еще не создали веб-сайт, как раз сейчас для этого подходящее время. В качестве имени проекта оставим предложенный вариант – Capella4.Web. Не рекомендуется изменять это значение по умолчанию, т.к. если пространство имен по умолчанию в веб-проекте не начинается с полного корневого пространства имен из Silverlight-проекта, то в RIA-сервисах могут появиться сложности, связанные с указанием строк ресурсов. Капелла будет работать как в Silverlight 4, так и в Silverlight5, поэтому выбираем просто ту версию, которая больше нам подходит. Включаем использование RIA-сервисов (это чекбокс Enable WCF RIA Services, который нужно отметить). В результате диалог создания веб-проекта из Visual Studio 11 будет выглядеть так:


Для полноты картины снимок получившегося проекта из Solution Explorer – оцените новые «серые» тона Visual Studio smile:):


В результате получаем:
  • Веб-проект Capella4.Web создан и назначен запускаемым проектом – это хорошо.
  • Для нас созданы на выбор две идентичные страницы Capella4TestPage.aspx и Capella4TestPage.html, одна из них уже назначена запускаемой страницей по умолчанию – это тоже хорошо. В результате, если мы просто запустим проект, то нам уже откроется в браузере наше Silverlight-приложение.
  • В проекте Capella4 присутствует файл MainPage.xaml. Этого нам не нужно – ядро Капеллы уже содержит свою главную страницу. Поэтому файл MainPage.xaml удаляем.
Теперь требуется добавить ссылки на сборки ядра Капеллы. В версии 4.0 сборки все еще распространяются в виде dll-файлов в папке, и нам нужно добавить их вручную через диалог Add Reference… Следующая версия ядра будет поддерживать пакеты NuGet и добавление ссылок на сборки ядра станет более простой задачей.
В проекте Capella4.Web требуется добавить ссылку на сборку Aurex.ClientModel.Web.dll. Также в файле web.config пока отсутствуют необходимые настройки для выполнения RIA-сервисов. Их можно либо добавить вручную, либо позволить сделать это самостоятельно, создав в проекте RIA-сервис. Для этого выберем Add -> New Item… и выберем Domain Service Class. В поле Name введем SimpleService.cs и нажмем ОК. Появится диалог параметров RIA-сервиса, который заполним следующим образом:

После нажатия ОК будет создан сервис, а необходимые настройки в web.config будут добавлены автоматически. Сам сервис мы пока использовать не будем (его даже можно удалить), но настройки из web.config пригодятся для работы сервисов, находящихся в Aurex.ClientModel.Web.dll. Вот такой вот хак.

В проекте Capella4 требуется добавить ссылки на следующие сборки ядра:
  • Aurex.Foundation.Silverlight.dll
  • Aurex.ClientModel.Silverlight.dll
  • Aurex.Shell.Silverlight.dll

После этого открываем файл App.xaml.cs и исправляем метод Application_Startup. Вместо явного присвоения переменной RootVisual экземпляра MainPage (этот класс мы удалили), вставляем запуск оболочки Aurex:

private void Application_Startup(object sender, StartupEventArgs e)
{
    Aurex.Shell.ShellApplication.Run();
}

Запускаем приложение. После запуска должна появиться следующая картина:


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

Служба аутентификации

Служба аутентификации в Капелле 4 должна удовлетворять следующим требованиям:
  1. Она должна находиться либо в запускаемом проекте, либо в одном из автоматически загружаемых модулей.
  2. Она должна представлять собой public-класс, реализующий интерфейс Aurex.ClientModel.Authentication.IAuthenticationService.
  3. Класс службы должен быть помечен атрибутом Aurex.ClientModel.Authentication.AuthenticationServiceAttribute (для того, чтобы можно было использовать этот атрибут, в проекте требуется добавить ссылку на System.ComponentModel.Composition).
Все методы IAuthenticationService используют асинхронную модель программирования – они существуют в виде пар Begin/End, работающих с IAsyncResult. Следовательно, реализуемая служба аутентификации может осуществлять взаимодействие с сервером для проверки подлинности пользователя (в Silverlight взаимодействие с сервером всегда выполняется в асинхронном режиме).
Если в проекте или модулях содержится несколько служб аутентификации, пользователь на странице входа в систему может выбрать требуемую службу. При этом пользователю отображается список доступных служб, в котором каждая служба представлена строкой имени, указанной в атрибуте AuthenticationServiceAttribute. Если пользователь успешно выполнил вход с помощью какой-либо службы, то при следующем запуске для этой службы будет вызван метод LoadUser. Служба может вернуть из этого метода аутентифицированного пользователя, в этом случае диалог входа в систему выдан не будет – так реализован механизм «запомнить меня» (т.е. механизм запоминания пользователя реализуется (либо может не быть реализован) в каждой службе отдельно, и служба сама выбирает механизм хранения учетной записи). Для входа пользователя с помощью формы используется метод Login, для выполнения выхода – метод Logout. В методе Login служба может сохранить учетную запись для последующего использования в LoadUser. В методе Logout служба может удалить сохраненную учетную запись, если она была сохранена.
RIA-сервисы имеют свой механизм аутентификации, выполняющий проверку подлинности на сервере через стандартный механизм аутентификации ASP.NET. Аутентификация через RIA-сервисы позволяет использовать контекст аутентифицированного в Silverlight пользователя в RIA-методах на стороне сервера. Аутентификация через RIA-сервисы является самой простой и удобной для приложений Silverlight. Для того чтобы ее использовать, необходимо унаследовать класс службы аутентификации от базового класса Aurex.ClientModel.Authentication.DomainAuthenticationServiceBase и реализовать только один метод – CreateDefaultUser. Метод CreateDefaultUser должен возвращать сгенерированный класс User из службы аутентификации RIA. Также служба должна быть соответствующим образом реализована в веб-проекте.
Итак, перейдем от теории к практике и создадим службу аутентификации через RIA-сервисы в нашем решении. Как уже отмечалось, RIA-сервисы используют аутентификацию ASP.NET, которая по умолчанию работает с базой данных SQL Server. Простейший способ ее использования предполагает, что на компьютере установлен экземпляр SQL Server Express с именем SQLEXPRESS. Если это не так, требуется создать базу данных membership и указать нужные настройки в файле web.config (более подробно см. в документации MSDN). Будем считать, что мы уже создали базу и завели в ней пользователей.
Начнем с создания стандартной инфраструктуры аутентификации через RIA-сервисы. Для этого в проекте Capella4.Web создадим раздел Services, затем в этот раздел добавим новый элемент Authentication Domain Service. Назовем соответствующий файл AuthenticationService.cs:


Созданный файл содержит реализацию RIA-службы аутентификации, названную AuthenticationService, а также используемый ей класс User. Сейчас нам менять этот файл не требуется. Приведем содержимое этого файла:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.ServiceModel.DomainServices.Hosting;
using System.ServiceModel.DomainServices.Server;
using System.ServiceModel.DomainServices.Server.ApplicationServices;

namespace Capella4.Web.Services
{
    [EnableClientAccess]
    public class AuthenticationService : AuthenticationBase<User>
    {
// To enable Forms/Windows Authentication for the Web Application, edit the appropriate section of web.config file.
    }

    public class User : UserBase
    {
        // NOTE: Profile properties can be added here 
        // To enable profiles, edit the appropriate section of web.config file.

        // public string MyProfileProperty { get; set; }

    }
}
Авторы этого файла намекают на то, что нужно также открыть файл web.conig и в секцию system.web добавить следующую запись:
<authentication mode="Forms" />
После добавления службы и редактирования файла web.config построим проект Capella4, чтобы в нем сгенерировался необходимый RIA-код. Теперь в проекте Capella4 откроем файл App.xaml.cs и добавим в конструктор App() инициализацию RIA-сервисов (добавленные строки выделены коричневым):
public App()
{
    var context = new WebContext();
    context.Authentication = new FormsAuthentication();
    ApplicationLifetimeObjects.Add(context);


    this.Startup += this.Application_Startup;
    this.Exit += this.Application_Exit;
    this.UnhandledException += this.Application_UnhandledException;

    InitializeComponent();
}

Теперь создадим службу аутентификации Капеллы. Для этого в проекте Capella4 создадим раздел Services и добавим в него файл AuthenticationService.cs со следующим содержанием:
using Aurex.ClientModel.Authentication;
using Capella4.Web.Services;

namespace Capella4.Services
{
    [AuthenticationService("RIA"smile;)]
    public class AuthenticationService : DomainAuthenticationServiceBase
    {
        protected override System.Security.Principal.IPrincipal CreateDefaultUser()
        {
            return new User();
        }
    }
}

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


В следующий раз мы немного заполним ленту и рабочую область. Созданное сегодня решение прилагается.

Капелла 4.0

Сегодня я расскажу о недавно вышедшей новой версии Капеллы – 4.0. Техническая версия имеет новое ядро под кодовым названием Aurex. Ключевые отличия нового ядра от старого заключаются в следующем:
  • Ядро написано заново.
  • Поддерживаемая версия Microsoft .NET Framework – 4.0 (в частности, WF 4.0 для написания сценариев).
  • Расширен набор поддерживаемых платформ: теперь поддерживаются WPF и Silverlight.
  • Разработка приложения с использованием нового ядра стала более простой и прямолинейной. Те сложности по созданию проекта, которые я описывал для Капеллы 3.5, больше не нужны – теперь достаточно создать проект приложения, подключить необходимые библиотеки и вызвать метод Run.
  • Ядро использует существующие технологии и практики, такие как Microsoft PrismManaged Extensibility Framework и др. – при разработке на новом ядре можно использовать существующие знания и навыки, а необходимость в конфигурировании (вспомним большое количество конфигурационных файлов в Капелле 3.5) сведена к минимуму.
  • Полностью переработанный интерфейс пользователя, на 100% расширяемый через API ядра с помощью модулей. Внешний вид и функциональность интерфейса идентичны на всех поддерживаемых платформах.
  • Измененный механизм доступа к данным. Доступ к данным осуществляется теперь на стороне сервера посредством сценариев, служб RIA (пока службы RIA поддерживаются только для Silverlight, но в будущем планируется поддержка и для WPF) и WCF, не требуя запуска специальной службы и генерации контекстных сборок.
  • Проверка подлинности пользователя (вход в систему) может использовать авторизацию ASP.NET, что позволяет использовать стандартные средства ограничения доступа на стороне сервера.

Демонстрация

Продемонстрирую более подробно Silverlight – версию демо-проекта (кодовое имя демо-проекта – Aurum). Для начала см. скриншот приложения (Silverlight в режиме вне браузера). Из скриншота видно, что интерфейс приложения состоит из трех основных частей:
1. Лента (ribbon), расположенная  в верхней части окна. Доступные вкладки и содержимое ленты могут добавляться с помощью внешних модулей.
2. Рабочие области, расположенные в основной части окна. Рабочие области имеют двухуровневый переключатель. Первый уровень называется «книга» (Workbook), второй – «лист» (Worksheet). Каждая книга является группой листов, которые могут быть закрыты одновременно (при закрытии книги). Некоторые листы также могут закрываться индивидуально, не требуя закрытия книги. Обычно в приложениях одна книга доступна при открытии приложения, а каждая новая книга создается при запуске сценария и закрывается при его завершении.
3. Перекрывающие закладки (Overlay) – это группа кнопок в нижней части окна (Информация, Календарь и т.д.). При нажатии на перекрывающую закладку ее содержимое отображается поверх содержимого книги (к книге можно вернуться, щелкнув ее заголовок). В перекрывающих закладках обычно размещаются справочники и другая информация, которая должна быть доступна всегда. Например, в одной из таких закладок может отображаться интерфейс модуля CRM, позволяющего открывать карточки объектов в виде листов в активной книге. С точки зрения программистов, перекрывающие закладки – это третий (самый верхний) уровень переключателя рабочих областей (невидимая первая закладка как раз соответствует изображенной на скриншоте ситуации, когда отображаются книги и листы).



Создание приложения

Расскажу вкратце о том, как пишутся приложения под новое ядро. Для начала создаем обычное Silverlight- или Wpf-приложение и добавляем ссылку на Aurex.Shell.dll. В процессе разработки могут потребоваться и ссылки на другие сборки. Например, большинство интерфейсов ядра находятся в сборке Aurex.ClientModel.dll.
Чтобы запустить приложение с использованием ядра Aurex, метод Application_Startup нужно реализовать следующим образом:
private void Application_Startup(object sender, StartupEventArgs e)
{
    Aurex.Shell.ShellApplication.Run();
}
Данный код выполняет новое ядро, создавая MEF-контейнер, содержащий сборку приложения. Все типы, помеченные атрибутом System.ComponentModel.Composition.ExportAttribute, будут проэкспортированы и автоматически использованы ядром. Кроме того, будет прочитан файл ModulesCatalog.xml, входящий в состав приложения. В файле ModulesCatalog.xml могут быть описаны модули Prism, которые требуется загрузить и проинициализировать. Для более подробной информации см. документацию по Prism.

Простой Export

Для начала сделаем что-нибудь простое, а именно укажем, что выводить в заголовке приложения. В демо-проекте Aurum нужно, чтобы в заголовке выводилось название «Aurum».
Ядро содержит множество интерфейсов. Некоторые из этих интерфейсов реализуются ядром и могут быть использованы в модулях посредством атрибута System.ComponentModel.Composition.ImportAttribue. Некоторые интерфейсы предназначены для реализации в приложении и его модулях. Для более подробной информации о таких интерфейсах нужно ознакомиться с документацией по ядру, которая будет доступна позже.
Чтобы указать название приложения, требуется реализовать интерфейс IApplicationBranding из пространства имен Aurex.ClientModel.Branding (опеределен в Aurex.ClientModel.dll). Этот интерфейс содержит всего одно свойство – string Name { get; }. Создадим в приложении файл ApplicationBranding.cs, содержимое которого должно быть следующим:
namespace Aurum.Application
{
    using System;
    using System.ComponentModel.Composition;
    using Aurex.ClientModel.Branding;

    [Export(typeof(IApplicationBranding))]
    public class ApplicationBranding : IApplicationBranding
    {
        string IApplicationBranding.Name
        {
            get { return "Aurum"; }
        }
    }
}

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

Использование модулей

Создадим теперь простой модуль, выводящий новую закладку в overlay-области.
Overlay-область представляется ядром клиентскому приложению в качестве области (region) в терминологии Prism. Имя области является константой OverlayRegion, хранящейся в классе Aurex.ClientModel.RegionNames. Для управления областями Prism предоставляет нам интерфейс Microsoft.Practices.Prism.Regions.IRegionManager, который можно использовать при инициализации модуля для добавления в область нового представления. Подробнее о Prism можно посмотреть в документации, а также ознакомиться с примерами, находящимися на сайте Codeplex.
Мы сейчас расмотрим максимально простой модуль. Ввиду его простоты класс, реализующий модуль, можно разместить непосредственно в приложении – Prism умеет инициализировать такие модули автоматически. При необходимости модули можно выносить в отдельные сборки и размещать описание модулей в файле ModulesCatalog.xml (для Silverlight-приложений этот файл поддерживается при условии, что для него указано действие при построении Resource).
Создадим в приложении файл Overlay.cs и напишем в нем такой код:

namespace Aurum.Application.SampleData
{
    using System;
    using System.ComponentModel.Composition;
    using System.Windows.Controls;
    using Aurex.ClientModel;
    using Aurex.ClientModel.Overlay;
    using Microsoft.Practices.Prism.MefExtensions.Modularity;
    using Microsoft.Practices.Prism.Modularity;
    using Microsoft.Practices.Prism.Regions;

    [ModuleExport("Aurum.Overlay", typeof(Overlay))]
    public class Overlay : IModule
    {
        [Import]
        public IRegionManager RegionManager;

        public void Initialize()
        {
            RegionManager.RegisterViewWithRegion(
                RegionNames.OverlayRegion,
                () => new OverlayItem { Header = "Информация", Content = new Button { Content = "Кнопка для вызова информации" } }
                );

            RegionManager.RegisterViewWithRegion(
                RegionNames.OverlayRegion,
                () => new OverlayItem { Header = "Календарь", Content = new Button { Content = "Кнопка для вызова календаря" } }
                );

            RegionManager.RegisterViewWithRegion(
                RegionNames.OverlayRegion,
                () => new OverlayItem { Header = "Аналитика", Content = new Button { Content = "Кнопка для вызова аналитиков" } }
                );
        }
    }
}

В качестве представлений закладок мы использовали класс OverlayItem из пространства имен Aurex.ClientModel.Overlay. Использование класса OverlayItem позволяет указать заголовок элемента, а внешний вид закладки предоставляется ядром; можно также использовать стандартное представление TabItem, но при этом внешним видом потребуется управлять самостоятельно. При наследовании от класса OverlayItem можно узнать, когда представление активировалось и деактивировалось, переопределяя методы OnActivated() и OnDeactivated(). OverlayItem можно активировать и деактивировать программно, меняя значение свойства IsActive.

Заключение

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

Почему CRM-системы не умеют создавать лояльных клиентов?



Record Centric системы
CRM-системы изначально были разработаны с целью хранения данных о клиентах для кросс-функциональных нужд различных отделов предприятий. Ранние версии систем предназначались для помощи в управлении продажами и отношениями с корпоративными клиентами и не были адаптированы для компаний, работающих на массовых рынках.

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

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

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

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

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

"Простой" сценарий

В прошлый раз я рассказал о том, как создать независимое приложение, использующее службы Капеллы. Это интересная задача, но основная часть работы с Капеллой связана не с написанием отдельных приложений, а с написанием форм, работающих непосредственно в клиентской части (АРМ) и сценариев, запускаемых сервером сценариев (workflow service). Сегодня я расскажу, как же это делается.

Сегодня мы займемся разработкой отдельного проекта (но уже внутри Капеллы) с одним очень простым и довольно классическим сценарием (Hello, User). Сценарий будет содержать две формы. На первой форме мы спросим имя пользователя, а на второй выведем приветствие для него. Мы пока не будем работать с базой данных – этим займемся в следующий раз.

Подготовка решения

Мы начинаем разработку нового проекта под Капеллу 3.5, и начать нужно с создания нового решения. Решение должно уже содержать проект CoreBinaries, о котором я рассказывал здесь

Если у вас уже есть решение CallSimulator, можно просто скопировать раздел, в котором находится это решение, называть новый раздел и находящийся в нем .sln-файл именем проекта (я назову его BlogProject) и удалить все подразделы, кроме CoreBinaries. Потом открыть этот .sln в Visual Studio и удалить все старые проекты, которые не смогли подгрузиться. У нас в решении останется один только CoreBinaries, и мы начинаем новый проект «с чистого листа». Решение в Visual Studio должно теперь выглядеть так, как показано на рисунке.



Создание проектов

Каждое решение для Капеллы обязательно имеет два проекта – это проект форм и проект сценариев. Обычно они называются как «ИмяРешения.Forms» (в нашем случае BlogProject.Forms) и «ИмяРешения.Workflow» (в нашем случае BlogProject.Workflow). Создадим эти проекты в Visual Studio, нажимая правой кнопкой на нашем решении и выбирая «Добавить / Создать проект». При добавлении проектов нужно выбрать .NET Framework 3.5 в качестве целевой версии.

Для создания проекта форм выбираем шаблон Visual C# / Windows / Библиотека пользовательских элементов управления WPF. Не забываем назвать проект «BlogProject.Forms». Для создания проекта сценариев выбираем шаблон Visual C# / Workflow / Библиотека последовательного рабочего процесса и называем проект BlogProject.Workflow. После того, как проекты будут созданы, удаляем из них файлы UserControl1.xaml и Workflow1.cs.

Настройка проектов

Чтобы Капелла смогла «увидеть» наши проекты, нужно расположить их определенным образом. Сборки с формами должны располагаться в разделе, названном именем проекта, и этот раздел должен быть расположен там же, где находится сервер безопасности (Security Service).

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

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

Итак, в нашем решении все серверы Капеллы находятся после построения в CoreBinaries/bin/Debug (или CoreBinaries/bin/Release), откуда они и запускаются нами с помощью скрипта startup.cmd. Поэтому нам требуется зайти в свойства созданных нами проектов форм и сценариев, перейти на страницу «Построение» и в поле «Путь вывода» указать:

- BlogProject.Forms, конфигурация Debug:
..\CoreBinaries\bin\Debug\BlogProject\
- BlogProject.Forms, конфигурация Release:
..\CoreBinaries\bin\Release\BlogProject\
- BlogProject.Workflow, конфигурация Debug:
..\CoreBinaries\bin\Debug\Applications\BlogProject\
- BlogProject.Workflow, конфигурация Release:
..\CoreBinaries\bin\Release\Applications\BlogProject\


Теперь добавляем ссылки на сборки Капеллы. При добавлении ссылок выбираем «Обзор» и переходим в раздел CoreBinaries\bin\Debug (проект CoreBinaries должен быть предварительно построен, чтобы сборки оказались там).

Для BlogProject.Forms добавляем ссылки на:

- C3.dll
- C3.AgentDesktop.dll
- C3.Application.dll
- C3.Application.Forms.dll
- C3.Communication.dll
- C3.Data.dll
- C3.Security.dll
- C3.Workflow.dll


Для BlogProject.Workflow добавляем ссылки на:

- C3.dll
- C3.Data.dll
- C3.Security.dll
- C3.Workflow.dll
- C3.Workflow.Activity.dll
- C3.Workflow.Application.dll


Теперь требуется включить ссылки на клиентские файлы .config в созданные нами проекты. Для этого нажмите правой кнопкой на проекте BlogProject.Forms, выберите «Добавить / Существующий элемент», перейдите в раздел CoreBinaries, отобразите файлы *.config, выделите следующие файлы:

- AuthorizationProvider.config
- CommunicationProvider.config
- DataProvider.config
- WorkflowProvider.config


Выделив эти файлы, нажмите стрелку справа от кнопки «Добавить» и выберите «Добавить как связь». Выделите добавленные файлы на панели обозревателя решений, и в их свойствах задайте для параметра «Копировать в выходной каталог» значение «Копировать, если новее». Теперь снимите выделение с файла WorkflowProvider.config (остальные три файла должны быть выделены) и перетащите их в BlogProject.Workflow, держа нажатой клавишу Ctrl.

Последним этапом подготовки файлов проектов будет создание файлов конфигурации. Создайте в проекте BlogProject.Forms файл App.config и скопируйте в него такое содержимое:

Код
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <sectionGroup name="c3.configuration" type="C3.Application.Configuration.ApplicationSectionGroup, C3.Application">
   <section name="implementation" type="C3.Activation.ImplementationSection, C3"/>
   <section name="application" type="C3.Application.Configuration.ApplicationSection, C3.Application"/>
   <section name="applicationtypes" type="C3.Application.Configuration.ApplicationTypesSection, C3.Application"/>
   <section name="libs" type="C3.Application.Configuration.LibsSection, C3.Application"/>
   <section name="forms" type="C3.Application.Configuration.FormsSection, C3.Application"/>
    </sectionGroup>
  </configSections>
  <c3.configuration xmlns="schemas://c3.configuration/Desktop/Application/">
    [i]
   <add interface="C3.Security.IAuthorizationProvider, C3" type="C3.Security.AuthorizationProvider, C3.Security"/>
   <add interface="C3.Communication.ICommunicationProvider, C3" type="C3.Communication.CommunicationProvider, C3.Communication"/>
   <add interface="C3.Application.IApplicationHostManager, C3.Application" type="C3.AgentDesktop.ApplicationHostManager, C3.AgentDesktop"/>
   <add interface="C3.Data.IDataProvider, C3" type="C3.Data.Proxy.ProxyDataProvider, C3.Data"/>
   <add interface="C3.Workflow.IWorkflowProvider, C3" type="C3.Workflow.WorkflowProvider, C3.Workflow"/>
   <add interface="C3.Application.IScreenCaptureProvider, C3.Application" type="C3.Application.ScreenCapture.ScreenCaptureProvider, C3.Application.ScreenCapture"/>
   <add interface="C3.Application.Forms.ICallControlProvider, C3.Application.Forms" type="C3.Application.Forms.BaseCallControlProvider, C3.Application.Forms"/>
   <add interface="C3.Application.Forms.Controls.EntityCard.IDataUpdater, C3.Application.Forms" type="C3.Application.Forms.Controls.EmptyDataUpdater, C3.Application.Forms" name="IDataUpdaterImpl"/>
    [/i]
    <applicationtypes>
   <add name="Workflow" type="C3.Application.Forms.WorkflowManager, C3.Application.Forms"/>
   <add name="Code" type="C3.Application.Forms.CodeManager, C3.Application.Forms"/>
   <add name="Win32" type="C3.Application.Win32.Win32HostFactory, C3.Application.Win32"/>
   <add name="Web" type="C3.Application.Web.WebHostFactory, C3.Application.Web"/>
    </applicationtypes>
    <application name="BlogProject" displayName="Капелла">
    </application>
    <forms>
   <add lib="BlogProject.Forms"/>
    </forms>
    <libs>
    </libs>
  </c3.configuration>
</configuration>
Теперь создайте файл App.config в проекте BlogProject.Workflow и скопируйте в него следующее:

Код
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <sectionGroup name="c3.configuration">
   <section name="implementation" type="C3.Activation.ImplementationSection, C3"/>
    </sectionGroup>
    <sectionGroup name="c3.workflow" type="C3.Workflow.Application.Configuration.WorkflowSectionGroup, C3.Workflow.Application">
   <section name="runtime" type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
   <section name="application" type="C3.Workflow.Application.Configuration.ApplicationSection, C3.Workflow.Application"/>
    </sectionGroup>
  </configSections>
  <c3.configuration>
    [i]
   <add interface="C3.Security.IAuthorizationProvider, C3" type="C3.Security.AuthorizationProvider, C3.Security"/>
   <add interface="C3.Communication.ICommunicationProvider, C3" type="C3.Communication.CommunicationProvider, C3.Communication"/>
   <add interface="C3.Application.IApplicationHostManager, C3.Application" type="C3.AgentDesktop.ApplicationHostManager, C3.AgentDesktop"/>
   <add interface="C3.Data.IDataProvider, C3" type="C3.Data.InstancingDataProvider, C3.Data"/>
   <add interface="C3.Workflow.IWorkflowProvider, C3" type="C3.Workflow.WorkflowProvider, C3.Workflow"/>
    [/i]
  </c3.configuration>
  <c3.workflow xmlns="schemas://c3.configuration/workflow/">
    <runtime Name="Hosting">
   <CommonParameters/>
   <Services>
     <add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" maxSimultaneousWorkflows="10"/>
   </Services>
    </runtime>
    <application>
    </application>
  </c3.workflow>
  <startup>
    <supportedRuntime version="v2.0.50727"/>
  </startup>
</configuration>
Настройка CoreBinaries

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

Откройте файл C3.Workflow.Service.WindowsService.exe.config. Найдите в этом файле элемент <c3.workflow.host>. Если он уже содержит элемент <applicationHost>, удалите его, а затем добавьте новое значение для <applicationHost>:
Код
<applicationHost>
  <applications>
    <add name="BlogProject"
      path="Applications\BlogProject"
      confFileName="BlogProject.Workflow.dll.config"/>
  </applications>
  <securityManager authSystemName="C3" userName="WorkflowServiceSima" password="Capella"/>
</applicationHost>
Мы задали раздел сборок сценариев нашего проекта относительно сервера сценариев, о чем я говорил выше. Теперь укажем параметры нашего проекта для C3.Starter.exe. Для этого откройте файл C3.Starter.exe.config, в котором найдите элемент <applications>, расположенный внутри <c3.starter>. Можно удалить все перечисленные там приложения (проекты), после чего добавить наше:

Код
<add name="BlogProject" appConfigName="BlogProject.Forms.dll.config">
  <autologon authSystem="C3" userName="comtest1" password="simasima" phone="101"/>
</add>
Теперь можно назначить проект BlogProject.Forms запускаемым проектом, открыть его свойства, перейти на страницу «Отладка», указать действие при запуске «Запуск внешней программы», выбрать в качестве внешней программы ..\CoreBinaries\bin\Debug\C3.Starter.exe (для конфигурации Release измените путь соответственно). В качестве аргументов командной строки укажите «BlogProject» без кавычек – это позволит приложению C3.Starter.exe выбрать нужное приложение при запуске, если в C3.Starter.exe.config указано несколько приложений.

Теперь запустим серверы Капеллы с помощью startup.cmd из CoreBinaries\bin\Debug. После успешного запуска серверов можно запустить наше решение. Запуск должен пройти успешно, и после загрузки должно появиться пустое окно Капеллы, изображенное на рисунке.



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

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

Создаем формы

Формы в Капелле – это элементы управления, обычно наследуемые от UserControl. Сценарии обращаются к формам по имени, являющемуся именем класса формы, поэтому классам форм нужно давать осмысленные имена.

Создадим первую форму в проекте BlogProject.Forms. Для этого нажмем на этом проекте правой кнопкой и выберем «Добавить / Пользовательский элемент управления». В поле с именем укажем «HelloInput.xaml» и нажмем кнопку «Добавить».

Как я и обещал, пока мы не будем работать с базой данных (универсальным хранилищем) и ограничимся пересылкой между формой и сценарием только строки (System.String). Чтобы можно было ссылаться на тип string, добавим определение соответствующего xmlns в наш xaml:
Код
xmlns:sys="clr-namespace:System;assembly=mscorlib"
Кроме того, нам потребуется пространство имен forms, содержащее элементы управления Капеллы:
Код
xmlns:forms="clr-namespace:C3.Application.Forms.Controls;assembly=C3.Application.Forms"
Параметры между сценариями и формами передаются двумя способами, мы пока будем использовать один из них – через ObjectDataProvider. Для этого определим ресурсы нашей формы следующим образом:
Код
[u]
    <ObjectDataProvider x:Key="UserName" ObjectType="{x:Type sys:String}" />
[/u]
Теперь зададим содержимое формы:
Код
<Grid Width="300">
    <Label Target="{Binding ElementName=UserName}" VerticalAlignment="Top">Ваше _имя:</Label>
     <TextBox x:Name="UserName" VerticalAlignment="Top" Margin="4,32,4,0" Text="{Binding Path=ObjectInstance, BindsDirectlyToSource=True, Source={StaticResource UserName}}" />
    <StackPanel Orientation="Horizontal" HorizontalAlignment="Right" VerticalAlignment="Top" Margin="4,60,4,0">
     <forms:FormActionButton Action="Next" Margin="4,0,0,0" Padding="12,2">_Далее</forms:FormActionButton>
     <forms:FormActionButton Action="Cancel" Margin="4,0,0,0" Padding="12,2">_Отмена</forms:FormActionButton>
    </StackPanel>
</Grid>
Как вы можете видеть, наша форма содержит TextBox, в котором мы просим пользователя ввести его имя. Введенное имя будет записано в ресурс UserName, который является ObjectDataProvider-ом. Это значение уйдет впоследствии в сценарий.

Также форма имеет две особые кнопки – FormActionButton. Когда пользователь нажимает на такую кнопку, команда из свойства Action передается в сценарий, а форма закрывается.

В привязке значения Text для TextBox мы использовали хитрость, позволяющую сделать двухстороннюю привязку имени пользователя к значению ObjectDataProvider целиком. Обычно в форму не передаются параметры примитивных типов, поэтому такая хитрость не требуется. 

Например, если бы мы передавали в форму параметр созданного нами класса UserInfo со свойством UserName, то тег для ObjectDataProvider имел бы вид <ObjectDataProvider x:Key="UserInfo" ObjectType="{x:Type local:UserInfo}" />, а привязка для свойства Text имела бы вид {Binding Path=UserName, Source={StaticResource UserInfo}}

Но для этого нам потребовалось бы создать проект общей сборки, в котором потребовалось бы разместить этот тип UserInfo (кстати, он должен быть XML-сериализуемым), и ссылаться на этот проект из BlogProject.Forms и BlogProject.Workflow, что усложнило бы наш чрезвычайно простой пример. Заметьте, что в форме HelloResult, приведенной ниже, данная хитрость тоже не требуется, т.к. привязка там односторонняя.

Итак, вот полный текст первой формы:
Код
[u]
    <UserControl.Resources>
     <ObjectDataProvider x:Key="UserName" ObjectType="{x:Type sys:String}" />
    [/u]
    <Grid Width="300">
     <Label Target="{Binding ElementName=UserName}" VerticalAlignment="Top">Ваше _имя:</Label>
     <TextBox x:Name="UserName" VerticalAlignment="Top" Margin="4,32,4,0" Text="{Binding Path=ObjectInstance, BindsDirectlyToSource=True, Source={StaticResource UserName}}" />
     <StackPanel Orientation="Horizontal" HorizontalAlignment="Right" VerticalAlignment="Top" Margin="4,60,4,0">
      <forms:FormActionButton Action="Next" Margin="4,0,0,0" Padding="12,2">_Далее</forms:FormActionButton>
      <forms:FormActionButton Action="Cancel" Margin="4,0,0,0" Padding="12,2">_Отмена</forms:FormActionButton>
     </StackPanel>
    </Grid>
</UserControl>
Файл HelloInput.xaml.cs (code behind) мы не трогаем.

Создадим теперь вторую форму, которая очень похожа на первую, и отображает введенное значение. Назовем форму HelloResult:
Код
[u]
    <UserControl.Resources>
     <ObjectDataProvider x:Key="UserName" ObjectType="{x:Type sys:String}" />
    [/u]
    <StackPanel Width="300">
     <StackPanel Orientation="Horizontal" VerticalAlignment="Top">
      <TextBlock>Добро пожаловать,</TextBlock>
      <TextBlock Margin="6,0,0,0" Text="{Binding Source={StaticResource UserName}}" />
      <TextBlock>!</TextBlock>
     </StackPanel>
     <StackPanel Orientation="Horizontal" HorizontalAlignment="Right" Margin="0,4,0,0">
      <forms:FormActionButton Action="Close" Margin="4,0,0,0" Padding="12,2">_Закрыть</forms:FormActionButton>
     </StackPanel>
    </StackPanel>
</UserControl>
Создаем сценарий

Теперь создаем сценарий, который будет работать на сервере сценариев и отображать пользователю последовательно две созданные формы. Сценарии создаются в проекте BlogProject.Workflow. Для создания сценария нажмите на проекте правой кнопкой и выберите «Добавить / Последовательный рабочий процесс». Сценариям тоже нужно давать осмысленные имена, поэтому назовите сценарий HelloUser.cs

Сразу после того, как отобразится дизайнер сценариев, перейдите в свойства (открываются по кнопке F4) и задайте для свойства «Класс Base» значение C3.Workflow.Activity.FlowchartDiagram. Для свойства «Description» задайте значение «Добро пожаловать» (этот текст будет отображаться не только в дизайнере, но также в АРМ на кнопке, соответствующей запущенному сценарию). Дизайнер сценария примет вид, показанный на рисунке.



Отобразите панель элементов. Если на панели элементов нет элементов, относящихся к Капелле, создайте новую вкладку панели и добавьте на нее элементы из библиотеки C3.Workflow.Activity.dll (библиотеку возьмите, например, из CoreBinaries\bin\Debug).
Для начала перетащите на панель дизайнера активность StartActivity. Затем перетащите ShowFormActivity, после чего еще один ShowFormActivity, и, наконец, FinishActivity.

Выделите первый ShowFormActivity и перейдите в окно свойств. Задайте для активности имя showInputForm, Description = «Ввод имени пользователя», FormName = «BlogProject.Forms.HelloInput». После этого дважды щелкните на активности. На странице «Параметры» нажмите кнопку «Добавить», в появившемся окне в поле «Имя параметра» напишите UserName, в поле «Тип параметра» оставьте System.String

Отметьте флажок «Исходящий параметр», т.к. имя будет приходить из формы в сценарий (см. рис.).



Затем перейдите на вкладку «Действия» и добавьте действия, которые могут быть переданы из формы (это параметры Action всех FormActionButton, расположенных на форме). Для этой активности требуется добавить действия Cancel и Next. После выполнения всех этих действий активность в дизайнере примет вид, приведенный на рисунке.



Кроме того, после добавления параметра к активности ShowFormActivity в окне свойств появилось новое свойство с именем параметра – UserName. Выберите это свойство и нажмите в столбце значиний кнопку с многоточием – отобразится диалог редактирования привязки сценария. Т.к. у нас в сценарии еще нет хранилища для имени пользователя, в диалоге переходим на страницу «Привязка к новому члену», выбираем «Создать поле» и в поле «Имя нового члена» вводим «UserName».



Теперь заполняем параметры второй активности ShowForm, отображающей форму HelloResult. Для начала сразу дважды щелкнем на активности, добавим параметр UserName типа System.String

На этот раз флажок «Исходящий параметр» оставляем неотмеченным. На странице «Действия» добавляем в соответствии с формой одно действие – Close. Теперь переходим в свойства активности и заполняем свойства следующим образом: (Name) = showResultForm, Description = Отображение результатов, FormName = BlogProject.Forms.HelloResult

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

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



Всё, сценарий готов.

Запуск сценария

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

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

Чтобы создать вкладку сценария, открываем файл App.config из проекта BlogProject.Forms. Мы уже создали в нем пустой элемент <application name="BlogProject" displayName="Капелла"> </application>. На самом деле внутри элемента <application> содержится список вкладок приложения, и нашу вкладку следует добавить сюда. Делаем это:
Код
<application name="BlogProject" displayName="Капелла">
  <add name="HelloUser" type="Workflow" params="BlogProject.Workflow.HelloUser"/>
</application>
Смысл типа Workflow уже задан в том же файле чуть выше, внутри элемента <applicationtypes> – это некий класс WorkflowManager. В качестве параметра он принимает имя сценария, в нашем случае это BlogProject.Workflow.HelloUser.

Теперь наше приложение готово к запуску. После запуска нам будет отображен уже не пустой экран, а форма сценария. Не очень красивая форма (теперь можно заняться дизайном smile:)), но все же простой сценарий реализован. 

Как полюбить клиента?

"Клиент не зависит от нашего существования. Это мы полностью зависим от него" Филип Котлер 

"Выбирая ваших клиентов, вы выбираете свое будущее" Сет Годин

"Клиент не может быть просто удовлетворен. Клиент должен быть доволен!" Майкл Делл



Клиенты бывают разными: черными, белыми, красными вспыльчивыми, скучными, сверхэрудированными или напротив, совсем не разбирающимися в предлагаемом продукте. Общее у них только одно: все они НАШИ клиенты и в равной степени заслуживают внимания и уважения.

Однако, эта мысль, казалось бы не требующая подтверждения, очень тяжело находит отклик во многих исполнительских головах. Это связано сразу с несколькими трудностями:
  • "клиентоориентированность" в сознании многих специалистов связана с каким-то "самоунижением" и пренебрежительным отношением к собственному труду
  • удовлетворение клиента часто противоречит бизнес-задачам, например длительное консультирование ведущими специалистами компании уже после завершения проекта
  • человеческий уровень терпимости, в принципе, не безграничен smile:)
Тем не менее, "нелюбимый" клиент вряд ли сможет долго сотрудничать с компанией-исполнителем, но при этом совершенно точно всем расскажет о своих впечатлениях. Согласно статистике, каждый недовольный клиент, в среднем, рассказывает об этом девяти из десяти своих знакомым, что особенно неприятно, учитывая глобальное интернет-пространство с одной стороны и высокую конкуренцию с другой.

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

Взаимоотношения с клиентом, если, конечно, это не "крайний" случай, должны строится на следующих постулатах:

1. "Клиент тоже может ошибаться". Это нужно понять и принять smile:) Ни бизнес, ни разработчик не совершенны, все могут ошибаться и принимать не верные решения. Только при условии взаимных уступок и компромиссов можно двигаться вперед.

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

3. "Ставьте себя на место клиента". Если вам откровенно нравится работать с этим решением, то есть основание полагать, что тоже будет и для клиента. А вот если уже вам не удобно выполнять поставленные бизнес-задачи, то странно ожидать этого от пользователей заказчика.

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

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

6. "Уважайте свой труд". Если вам самим не нравится как вы работаете, раздражают свои сотрудники  и просто бесит smile:) собственное решение это автоматически передастся вашему клиенту.

Экспертная система в обслуживании клиентов



Когда-то мы все интересовались условиями предоставления кредитов, страховок, вкладов, тарифных планов и других продуктов…

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

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

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

Как работает экспертная система?

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

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

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

Применение экспертных систем в каналах взаимодействия

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

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

Call Simulator. Часть 2

Продолжаем реализовывать симулятор входящих звонков. В первой части мы создали в Visual Studio исходную структуру решения (Solution), с которой начинается разработка любого приложения, использующего ядро Капеллы. Исходная структура – это проект CoreBinaries, в который мы добавили основные файлы *.config, а всё остальное добавляется ядром автоматически.

Обычно мы добавляем в решение CoreBinaries такие файлы конфигурации (как это выглядит в Visual Studio, показано на рисунке):



- C3.Security.Service.exe.config
- C3.Data.Service.WindowsService.exe.config
- C3.Communication.Service.exe.config
- C3.Workflow.Service.WindowsService.exe.config
- AuthorizationProvider.config
- CommunicationProvider.config
- DataProvider.config
- WorkflowProvider.config
- C3.Starter.exe.config

Теперь займемся непосредственно созданием проекта CallSimulator. Создадим в решении CallSimulator одноименный проект, выбрав в качестве шаблона Приложение WPF, использующее среду выполнения .NET Framework 4. В проекте уже есть файл для главного окна – MainWindow.xaml, его мы и будем использовать при разработке.

Сначала требуется добавить ссылки на нужные сборки ядра. Нам потребуются следующие сборки:

- C3.dll
- C3.Security.dll
- C3.Communication.dll
- C3.LightClient.dll

Добавьте ссылки на эти сборки в проект CallSimulator, взяв их из подраздела bin\Debug проекта CoreBinaries.

ПРИМЕЧАНИЕ: Если мы захотим собрать финальную (Release) сборку нашего проекта, то указанный при добавлении ссылок путь CoreBinaries\bin\Debug приведет к тому, что в выходной раздел bin\Release проекта будут скопированы отладочные сборки ядра. Это можно исправить либо вручную после сборки проекта (перезаписав отладочные версии финальными после сборки), либо автоматизировать. Для автоматизации нужно отредактировать файл проекта (CallSimulator) вручную. Пути к сборкам в нем отображаются в виде XML-элементов <HintPath>. Нужно в этих путях заменить …\bin\Debug\... на …\bin\$(Configuration)\...

Кроме того, нам потребуется добавить ссылку на System.Web, для этого в свойствах проекта смените требуемую версию .NET Framework с .NET Framework 4 Client Profile на .NET Framework 4. Удалите файл app.config, появившийся в решении после смены версии .NET Framework, т.к. он нам не потребуется. После смены требуемой версии .NET Framework добавьте ссылку на сборку System.Web.

Теперь в проект нужно добавить требуемые нам файлы конфигурации. Приложение CallSimulator будет подключаться к серверу авторизации и коммуникации, поэтому нам потребуются AuthorizationProvider.config и CommunicationProvider.config. Добавим эти файлы в проект CallSimulator как ссылки на одноименные файлы из проекта CoreBinaries. Для этого нажмем правой кнопкой на проект CallSimilator, выберем Добавить / Существующий элемент, перейдем в раздел CoreBinaries и выберем указанные два файла, после чего нажмем стрелку справа от кнопки Добавить и выберем Добавить как связь. Теперь выделяем добавленные в проект ссылки, открываем свойства (обычно по кнопке F4) и для параметра Копировать в выходной каталог выбираем Копировать, если новее. Теперь наше решение выглядит так:



Откройте файл MainWindow.xaml в дизайнере и добавьте определение пространства имен C3.LightClient, а также требуемый нам объект Communicator в ресурсы окна и как контекст данных для контейнера Grid:

Код
<Window x:Class="CallSimulator.MainWindow"
        xmlns="[url]http://schemas.microsoft.com/winfx/2006/xaml/presentation[/url]"
        xmlns:x="[url]http://schemas.microsoft.com/winfx/2006/xaml[/url]"
        xmlns:lc="clr-namespace:C3.LightClient;assembly=C3.LightClient"
        Title="Simple Call Simulator" Height="350" Width="525"
        ResizeMode="CanMinimize" SizeToContent="Height" WindowStartupLocation="CenterScreen">
        <Window.Resources>
        <ObjectDataProvider x:Key="Communicator" ObjectType="{x:Type lc:CommunicationClient}" DataChanged="Communicator_DataChanged"/>
        [b]
    </Window.Resources>
    <Grid DataContext="{StaticResource ResourceKey=Communicator}">
        
    </Grid>
</Window>

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

Добавив такой код, мы создали привязку, для которой в дизайнере будет доступен IntelliSense, т.к. в ней содержится информация о типе объекта – C3.LightClient.CommunicationClient. Но для того, чтобы установить подключение к серверу коммуникации, нам потребуется написать немного кода.

Для начала нажмем правой кнопкой на событие Communcator_DataChanged и выберем Перейти к обработчику событий, в результате чего мы попадем в редактор исходного кода формы, в которой создастся обработчик события. Мы будем использовать в коде пространство имен C3.LightClient, поэтому добавим такую строку в начало файла:

Код
using C3.LightClient;

Чтобы установить связь с сервером коммуникации, сначала нужно авторизоваться на сервере авторизации. Для этого нам нужен объект клиента авторизации. Заведем для него поле в классе MainForm (заодно и поле для клиента коммуникации):

Код
// Подключение к серверу авторизации
private SecurityClient _security;
// Подключение к серверу коммуникации
private CommunicationClient _communication;

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

Код
public MainWindow()
{
    InitializeComponent();
    // Создаем подключение к серверу авторизации
    _security = new SecurityClient();
    // Выполняем авторизацию
    _security.Start("C3", "comtest2", "simasima");
    // Передаем объект _security в качестве параметра конструктора
    // для подключения к серверу коммуникации
    ((ObjectDataProvider)FindResource("Communicator")).
        ConstructorParameters.Add(_security);
}

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

Существует также общая (т.е. унаследованная от класса Connector) версия метода Start без параметров, позволяющая запустить подключение с теми же параметрами повторно (для первого подключения вызывать метод без параметров нельзя). После вызова Start, если не произошло критических исключений, подключение остается запущенным, пока не будет вызван метод Stop. В запущенном состоянии подключение не всегда будет установлено (установлено ли подключение в данный момент, можно узнать из свойства IsConnected).

Если соединение не установлено при запущенном подключении, это значит, что произошла ошибка либо разрыв подключения. О наличии и причине разрыва подключения сигнализируют свойства HasLostReason, LostReason и LostReasonMessage. Мы используем эти свойства на форме чуть позже, чтобы отобразить сообщение пользователю. Также объект подключения содержит свойство State, сообщающее о состоянии подключения более подробно.

Если объект подключения запущен, то в случае разрыва соединения он переходит в состояние «потерян» (Lost), в котором периодически выполняются попытки восстановления подключения в автоматическом режиме.

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

Теперь пишем обработчик события Communicator_DataChanged. Задачей этого обработчика является вызов метода Start с подходящими параметрами для объекта CommunicationClient, если он создан в ObjectDataProvider:

Код
private void Communicator_DataChanged(object sender, EventArgs e)
{
    // Получаем объект CommunicationClient
    var communication = ((ObjectDataProvider)sender).
        Data as CommunicationClient;
    // Устанавливаем подключение к серверу коммуникации
    // с номером телефона 100
    if (communication != null)
    {
        communication.Start("100", null, null, null);
        // Сохраняем объет коммуникации для обрабоки кнопок
        _communication = communication;
    }
 }

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

Теперь размещаем элементы управления на форму, пользуясь привязками к контексту данных, которым является CommunicationClient:

Код
<Grid DataContext="{StaticResource ResourceKey=Communicator}">
    <StackPanel Orientation="Vertical" Margin="12,0,12,12">
        <TextBlock Text="{Binding Path=State}"
                   VerticalAlignment="Top" Margin="0,12,0,0" />
        <TextBlock Text="{Binding Path=LostReasonMessage}"
                   VerticalAlignment="Top" Margin="0,12,0,0"
                   Visibility="{Binding Path=HasLostReason, Converter={StaticResource BVC}}"
                   TextWrapping="Wrap" />
        <Control Margin="0,12,0,0" HorizontalAlignment="Right"
                 Visibility="{Binding Path=IsConnected, Converter={StaticResource BVC}}">
            <Control.Template>
                <ControlTemplate>
                    <StackPanel Orientation="Horizontal">
                        <Button x:Name="Call" IsEnabled="False" Margin="8,0,0,0" Padding="12,2" Click="Call_Click">Call[/b]
                        [b]Hang Up[/b]
                    </StackPanel>
                    <ControlTemplate.Triggers>
                        <DataTrigger Binding="{Binding Source={StaticResource Communicator}, Path=CommunicationStatus.PhoneStatus}" Value="Open">
                            <Setter TargetName="Call" Property="IsEnabled" Value="True"/>
                            <Setter TargetName="HangUp" Property="IsEnabled" Value="False"/>
                        </DataTrigger>
                    </ControlTemplate.Triggers>
                </ControlTemplate>
            </Control.Template>
        </Control>
    </StackPanel>
</Grid>

Последним шагом будет написание обработчиков для кнопок – Call_Click и HangUp_Click. Реализуем эти обработчики, пользуясь сохраненной ссылкой на объект _communication:

Код
private void Call_Click(object sender, RoutedEventArgs e)
{
    // 101 - это номер телефона, на который делаем звонок
    if (_communication != null) _communication.Call("101", null);
}

private void HangUp_Click(object sender, RoutedEventArgs e)
{
    if (_communication != null) _communication.HangUp();
}

Теперь всё готово к запуску симулятора звонков. Не забудьте перед запуском симулятора зайти в раздел CoreBinaries\bin\Debug и запустить службы Капеллы с помощью скрипта startup.cmd. Правда, можно и не запускать службы Капеллы или остановить их во время выполнения приложения и потом перезапустить.

Наше приложение автоматически это отследит и установит соединение при первой возможности благодаря функциональности, заложенной в библиотеку облегченного клиента C3.LightClient. Теперь можно запустить АРМ Капеллы, зайти в него с номером телефона 101 и выполнить звонок через симулятор – в АРМ запустится сценарий входящего звонка.

Call Simulator. Часть 1

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

Для создания приложения нам потребуется Microsoft Visual Studio 2010 и дистрибутив ядра Капеллы.

Начало

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

Начнем с создания в Visual Studio пустого решения. Нажмем для этого Создать проект / Другие типы проектов / Решения Visual Studio / Новое решение. Назовем решение CallSimulator, разместить его можно в любом месте.

В решении создадим проект с названием CoreBinaries. Этот проект требуется создать как библиотеку классов (нажимаем правой кнопкой на решении, Добавить, Создать проект, выбираем Visual C# / Библиотека классов). В качестве платформы выбираем Microsoft .NET Framework 4. Удаляем файл Class1.cs. Теперь нужно отредактировать файл проекта, чтобы проставить в нем ссылку на дистрибутив Капеллы.

Чтобы отредактировать файл проекта в Visual Studio, выгружаем проект (нажимаем правой кнопкой мыши на проекте CoreBinaries и выбираем Отменить загрузку проекта), а потом открываем проект на редактирование (снова нажимаем правой кнопкой на проекте CoreBinaries и выбираем Изменить CoreBinaries.csproj).

Для того чтобы понять содержимое файла проекта, требуется прочитать документацию по MSBuild. Скажу вкратце, что файл проекта C# – это xml-файл особого формата, для большинства тегов которого в Visual Studio действует IntelliSense. Чтобы добавить ссылку на ядро, для начала требуется определить свойство проекта CoreDir.

Свойства проекта находятся внутри тега <PropertyGroup> и являются xml-элементами, содержимое свойств – это их значения. Добавьте элемент <CoreDir> внутрь элемента <PropertyGroup>, не имеющего атрибутов Condition (см. рис.).



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

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

Указав CoreDir, находим тег <Import> в файле проекта и добавляем после него еще один:
<Import Project="$(CoreDir)C3.Common\Targets\CoreBinaries.files" />
(если CoreDir указывает на двоичный дистрибутив, заменяем C3.Common на $(Configuration)).

После всех исправлений перезагружаем проект в Visual Studio, нажав на нем правой кнопкой и выбрав Перезагрузить проект. В проекте должен появиться раздел IntelliSense, а после его построения в подразделе bin\Debug должны появиться сборки ядра.

ПРИМЕЧАНИЕ. В настоящее время при подключении файла CoreBinaries.files из двоичного дистрибутива не будут автоматически подключены файлы IntelliSense, т.к. Visual Studio не поддерживает включение файлов с условиями. Чтобы файлы IntelliSense появились при подключении двоичного дистрибутива, нужно в CoreBinaries.files раскомментарить фрагмент, идущий после комментария Закомментарено, т.к. VisualStudio игнорирует Condition для ItemGroup.

Работа со службами

Мы создали раздел CoreBinaries, содержащий ссылку на ядро Капеллы. Наше решение теперь выглядит так:



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

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

Я рекомендую добавить файлы C3.Data.Service.WindowsService.exe.config (позволит нам отредактировать строку подключения к базе данных) и C3.Workflow.Service.WindowsService.exe.config (позволит нам указать расположение разделов Worfkflow, а в данном случае вообще их удалить, чтобы сервер сценариев мог запускаться без ошибок).

Для изменения строки подключения к базе данных нужно в файле C3.Data.Service.WindowsService.exe отредактировать элемент <connectionStrings>. Для удаления разделов Workflow в файле C3.Workflow.Service.WindowsService.exe удаляем все элементы <folders>, находящиеся по пути <c3.workflow.host>/<applicationHost>. Отредактировав файлы конфигурации, строим решение еще раз и проверяем, что файлы в bin\Debug обновились.

Теперь нужно выполнить первоначальную настройку служб, для чего запускаем из раздела bin\Debug файл install.cmd от имени администратора. При этом запустятся серверы авторизации и универсального хранилища, после чего нужно подождать, пока загрузка процессора сервером универсального хранилища упадет до нуля (т.е. он построит все контексты данных), а затем можно остановить серверы запуском от имени администратора файла shutdown.cmd.

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

netsh http add urlacl url=http://+:8000/ user=DOMAIN\USERNAME listen=yes
netsh http add urlacl url=http://+:8005/ user=DOMAIN\USERNAME listen=yes
netsh http add urlacl url=http://+:8080/ user=DOMAIN\USERNAME listen=yes
netsh http add urlacl url=http://+:8107/ user=DOMAIN\USERNAME listen=yes

DOMAIN\USERNAME нужно заменить на используемую в процессе разработки учетную запись пользователя.

Теперь всё настроено и можно запустить службы в обычном режиме с помощью скрипта startup.cmd. Для отладки проектов всегда требуется запускать службы из проекта CoreBinaries соответствующего решения. Чтобы изменить или добавить хранилище данных, можно использовать MMC snap-in C3.Management.msc.

В следующий раз

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

Архитектура системы версии 3

Здравствуйте smile:), меня зовут Михаил, и я представляю направление развития продукта.

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

Начнем с общей архитектуры системы версии 3 (это текущая версия). В разработке находится версия 4, но о ней мы поговорим позже.

Архитектура

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

- Сервер авторизации
- Сервер универсального хранилища
- Сервер коммуникации
- Сервер сценариев

Серверная часть имеет интерфейс настройки, выполненный в виде MMC snap-in. Клиентская часть – это приложение, называемое Agent Desktop или АРМ (Автоматизированное рабочее место). Все части системы используют Microsoft .NET Framework 3.5 SP1.

Серверная часть

Подробно о каждом сервере поговорим в следующий раз. Сейчас скажу, что каждый сервер состоит из EXE-файла и нескольких используемых им DLL. EXE-файл можно установить с помощью утилиты InstallUtil, которая входит в состав Microsoft .NET Framework, в этом случае он будет зарегистрирован в качестве службы. Можно запустить EXE-файл без установки с параметром /Debug, в этом случае он просто будет запущен в фоновом режиме.

Серверы системы построены на технологии WCF (Windows Communication Foundation). К каждому EXE-файлу сервера прилагается файл конфигурации, в котором можно настроить его конечные точки (WCF endpoints). Каждый сервер может запускаться на отдельном компьютере, хотя это необязательно.

Взаимодействие с серверами системы осуществляется с помощью поставщиков (providers). Это соответственно AuthorizationProvider, DataProvider, CommunicationProvider и WorkflowProvider. Каждый поставщик работает с одноименным файлом конфигурации (например, AuthorizationProvider использует конфигурацию из файла AuthorizationProvider.config). Файлы конфигурации поставщиков должны находиться в разделе использующего их приложения. Файл конфигурации поставщика – это файл конфигурации клиента WCF, в котором также описаны конечные точки и параметры подключения к соответствующим серверам.

Сборки

В систему «Капелла» входит ряд сборок. Основная сборка, используемая всеми серверами и клиентской частью системы – это C3.dll. В ней находятся определения протоколов взаимодействия с серверами, а также класс C3.Session, дающий доступ ко всем серверам системы.

Каждому серверу соответствует сборка, содержащая поставщика. Это C3.Security.dll, C3.Data.dll, C3.Communication.dll и C3.Workflow.dll. Каждый сервер использует только свою библиотеку поставщика, а клиенту могут потребоваться несколько или все сразу. Каждый сервер может иметь ряд DLL с производными именами (например, сервер сценариев имеет C3.Workflow.Application.dll, C3.Workflow.Service.dll и др.).

К клиентской части относятся сборки C3.AgentDesktop.dll, C3.Application.dll, C3.Application.Forms.dll и другие, начинающиеся с C3.Application.

Клиентская часть

Стандартный клиент для системы «Капелла» – AgentDesktop – запускается с помощью файла C3.Starter.exe. Файл C3.Starter.exe и файл конфигурации C3.Starter.exe.config – это единственные два файла, необходимые для запуска клиентской части на компьютере пользователя. В файле конфигурации указывается имя приложения и параметры подключения к серверу обновлений. Файл C3.Starter.exe читает конфигурацию, подключается к серверу обновлений и выполняет обновление раздела приложения с сервера обновлений (сервер обновлений – это одна из составных частей сервера авторизации).

В результате при каждом запуске C3.Starter.exe будет запущена самая свежая версия приложения (при первом запуске, когда приложение еще не было загружено, оно автоматически загружается полностью). После обновления выполняется запуск приложения в соответствии с его файлом конфигурации.

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

Что еще есть в системе

В системе есть еще несколько сборок. Одна из них – это C3.WebClient.dll. Это библиотека, предназначенная для создания «тонкого» клиента – веб-сайта, работающего в IIS. Библиотека тонкого клиента позволяет использовать на сайте авторизацию «Капеллы» и подключаться к универсальному хранилищу.

Другая библиотека – C3.LightClient.dll – это библиотека «легкого» клиента, которая служит для создания простых клиентских приложений, работающих с серверами коммуникации и сценариев. Библиотека легкого клиента предоставляет средства отслеживания разрывов подключения и автоматического его восстановления, а также дает более простой и прямолинейный интерфейс для доступа к функциям серверов. Сервер сценариев имеет свою библиотеку активностей – C3.Workflow.Activity.dll.

Заключение

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

О требованиях к продукту


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

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

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

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

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

Выделенные уровни позволяют с одной стороны "спускаться" от общего к частному, сохраняя последовательность и корректность, а с другой стороны зафиксировать требования от разных слоев населения smile;) представителей заказчика.

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

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

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

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

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


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

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

Единое рабочее место оператора контакт-центра

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

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

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

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

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

Основные причины создания единого рабочего места оператора

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

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

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

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

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

3. Рост удовлетворенности операторов – залог эффективности их работы
Работа оператора контакт-центра нелегка. Известно, что около 60-70% затрат call-центра приходится на зарплату операторов. Чтобы подготовить готовую «боевую единицу» необходимо обучить и натренировать сотрудника, этот процесс может занять несколько недель. И даже после этого пройдет несколько месяцев до того момента, как оператор начнет работать эффективно. Кроме того высокая текучесть кадров данной профессии затрудняет процесс удержания лучших сотрудников.

В соответствии с исследованиями Benchmark Portal один из трех операторов контакт-центра, отвечающих на телефонный звонок, является новым или менее опытным. Когда запрос обрабатывается на низком уровне, вероятность повторной продажи ниже 30%, в то же самое время, при высоком уровне обработки обращения вероятность повторных продаж вырастает до 90%.

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

53% руководителей call-центров считают «эмоциональное выгорание» на работе ключевым препятствием на пути достижения качественного обслуживания. 85% из опрошенных уверены, что на «эмоциональное выгорание» оказывает влияние разнообразие программных приложений, используемых в работе. Следовательно, упрощение доступа к ресурсам компании окажет огромное влияние на удовлетворенность оператора, а, следовательно, и удовлетворенность клиентов.

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

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

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

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

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

Ах это "23 февраля" :)

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

В настоящее время 23 февраля - это всенародный праздник настоящих мужчин и защитников Отечества, которых в нашей компании подавляющее большинство smile:)

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

С праздником, дорогие мужчины!











Поделитесь информацией