Компания «Мобильные телесистемы» (МТС) первой из сотовых операторов «большой тройки» предложила корпоративным клиентам новый вид услуг — выдачу электронных подписей, сообщили Digit.ru в компании.

МТС приступила к продаже сертификатов усиленных квалифицированных электронных подписей на USB-носителях (токенах), выдаваемых собственным аккредитованным удостоверяющим центром МТС. Электронная подпись позволяет юридическим лицам — клиентам МТС заверять документы и идентифицировать их авторство в электронном виде. Использование электронных подписей ускоряет делопроизводство за счет отказа от использования и пересылки документов в бумажном виде.

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

Абонентская плата за выдачу электронной подписи и техническую поддержку на защищенном носителе составляет 2999 рублей в год, на носителе клиента — 1999 рублей в год. МТС планирует, что в 2014 году электронные подписи подключат более чем 10% ее корпоративных клиентов.

Согласно принятой в августе 2013 года стратегии развития электронного документооборота (ЭДО) МТС до 2018 года, оператор планирует начать предоставление услуг оператора ЭДО своим клиентам, а также внедрить электронный документооборот внутри компании — в работе с поставщиками, корпоративными и частными абонентами.

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

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

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

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

Поэтапная реализация проекта перехода на электронный документооборот с применением усиленной квалифицированной электронной подписи будет происходить в течение 2014–2016 гг. До конца 2016 года МТС планирует заработать на продаже услуг удостоверяющего центра и оператора ЭДО более 2 миллиардов рублей, дополнительно около 150 миллионов рублей оператор планирует сэкономить за счет внедрения ЭДО внутри компании.

Так, по оценке Федеральной налоговой службы (ФНС), в России ежегодно выписывается около 15 миллиардов счетов-фактур, в то же время, в 2012 году в системах электронного документооборота было передано менее 10 миллионов электронных документов. Для сравнения, в странах ЕС в конце 2013 года этот показатель должен составить около 20%, а по всему миру — 5%. По прогнозу ФНС, к концу 2013 г. крупнейшие компании РФ планируют перевести в электронный формат до 50% документов.

Интервью с Максимом Кайнером, бизнес-аналитиком компании DIRECTUM о трендах: мобильность, облака, неструктурированные данные, для журнала «Директор информационной службы».

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

ECM-система должна иметь мобильный клиент, чтобы отвечать потребностям бизнес-заказчиков. Эксперты Gartner к 2016 году предсказывают четырехкратный рост затрат на покупку планшетов для нужд бизнеса, что поспособствует тому, что около 40% всех сотрудников станут мобильными. Прогнозы аналитиков Forrester гласят о том, что к 2016 году в мире будет 20 миллионов пользователей корпоративной мобильности. А по данным IDC уже сегодня около 35% всех работников можно отнести к категории «мобильных сотрудников».

Мобильный клиент ECM-системы востребован со стороны топ- и мидл-менеджеров. Основные сценарии работы – рассмотрение документов, анализ KPI, выдача поручений. Окупается внедрение мобильных решений за счет ускорения и обеспечения непрерывности процессов принятия решений.

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

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

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

Анализ неструктурированных данных – реальность или миф?

Реальность. Существуют инструменты для извлечения структурированных данных из огромного объема неструктурированного контента. К примеру, это касается анализа текстов на естественном языке. Технологии, позволяющие решать такие задачи, применяются компаниями Google, Yandex и другими.

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

При этом хоть в ECM-системе может храниться большой объем данных (до десятков терабайт), но этот объем меньше, чем в биллинговых или ERP-системах, а также в некоторых некорпоративных системах (к примеру, во время XXX Олимпиады объем одновременно передаваемых данных составлял 1,4 ТБ, а всего в системах хранились сотни терабайт информации). При таких объемах информации анализ неструктурированных данных более востребован. Здесь стоит выделить технологии, тесно связанные с анализом больших данных. Это In-memory database management system, Cloud computing, In-memory analytics и Predictive analytics.

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

Какие еще направления развития Вы видите?

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

Перспективны социализация и геймификация. ECM-cистема, позволяющая сотрудникам общаться на рабочие темы, объединяющая их в круги по профессиональным интересам, показывающая ленты новостей друзей-коллег, дающая возможность ставить лайки и дислайки, – это шаг в направлении повышения коллективной производительности. 41% молодых специалистов, по данным исследования PwC за 2011 год, предпочитали общаться на работе в электронном виде, а не лично!

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

Полностью интервью опубликовано в журнале «Директор информационной службы», январь, 2014.

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

Временные решения

При проектировании интерфейса (и программ вообще) достаточно часто сталкиваешься с ситуацией: «А давайте сделаем кнопку (окно, диалог и т.п.) пока такой (пусть и не очень подходящей), а потом при необходимости переделаем…». Так часто происходит, когда время поджимает, красивое решение сразу не находится и, вообще, «Мы же гибко разрабатываем - потом вернёмся и доделаем».

НО это «потом» наступает не всегда! Временные решения любят становиться постоянными и прорастать корнями в ИС так, что потом их не выдерешь. В таких случаях можно рекомендовать больше времени выделять на проектирование и поиск подходящих решений; или быть настоящим перфекционистом и улучшать временные решения на следующих итерациях (версиях).

Диалоги

Наверняка многие из вас сталкивались — и сталкиваются — с неадекватными или не понятными диалогами. Особенно программисты любят выдавать пользователям не понятные им сообщения об ошибках формата «Error 3456: нет возможности записать сведения в таблицу …». Что он хотел этим сказать пользователю? Он действительно считает, что пользователь его поймёт? Зачем вообще пользователю видеть такой текст ошибки?

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

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

Объект с таким наименованием существует.

[да]     [нет]

(Тут кроме неадекватного диалога ещё и добавился баг некорректной проверки уникальности наименования).

Господа разработчики, чаще ставьте себя на место пользователя и задавайте себе вопросы: А зачем я делаю такой диалог? А поймёт ли меня пользователь? А что я хочу от пользователя в этом диалоге получить?

Быстродействие глазами пользователя

Быстродействие глазами пользователя ≠ быстродействие глазами разработчика. Почему спросите вы? А вот почему.

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

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

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

Простота vs Сложность

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

Хороший пример реализации простоты интерфейса – продукция Apple - колесо для iPod (в iPod Shuffle даже дисплея нет, но им пользоваться очень просто); минимализм кнопок практически в любом продукте Apple; мультитач-интерфейсы под естественные движения пальцев и многое другое. Дизайну и интерфейсу Apple уделяло огромное внимание, очень тщательно его проектировало, Стив Джобс был ужасным перфекционистом. Рекомендую прочитать книгу Уолтера Айзексона «Стив Джобс».

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

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

Роль интерфейса при продаже ИС

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

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

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

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

Минимально функциональный продукт

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

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

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

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

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

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

А какие у вас есть заметки и подходы к проектированию интерфейсов?

Комментарий к статье «Алексей Митин, «Реал»: В основе взаимодействия электронный документ».

Если в контексте ERP-систем существует стандарт EDI, то, например, для ECM-систем таким можно считать CMIS. Сейчас, когда это стало возможно, появляются сервисы для обмена юридически значимыми документами.

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

Новые сервисы по отдельности, как правило, не обладают широким функционалом. Они решают одну задачу, зато безупречно. Впрочем, когда мы говорим о сервисах уровня Enterprise, ситуация несколько иная, сопоставимая с тем, что происходило с «маленькими» сервисами год, два или пять лет назад. Отдельно хочется обратить внимание на упомянутых в интервью EDI-провайдеров. В статье выдвигается очень зрелая мысль о том, что их участие помогает избежать однообразных и назойливых проблем по адаптации собственной ERP-системы под разные форматы, которые каждый участник информационного взаимодействия когда-то для себя принял. Присутствие провайдеров очень важно и действительно помогает избежать множества проблем по адаптации ERP, но рискну предположить, что дальнейшее развитие ИТ в глобальных масштабах приведёт к более точному соблюдению стандартов и, как следствие, к быстрому снижению необходимости в провайдерах услуг контроля и трансформации документов для приведения их в соответствие требованиям участника-получателя. В отношении EDI есть ещё одна интересная идея. Она утверждает, что внедрение подобных систем будет порождать оборот таких электронных документов, каких в бумажном виде просто никогда не существовало, например Advanced Shipment Notification.