Konica Minolta

Мигрировать на доступные в РФ сервисы, как облачные, так и on-premise.

Если подняться на уровень выше, можно задуматься о том, что по факту Service-Desk, CRM и СЭД - это набор настроенных бизнес-процессов в любой достаточно гибкой платформе, типа BPM или корпоративного портала.

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

Начнём с того, что сейчас рынок сервис-десков несколько изменился. Процитирую одного из спикеров конференции iTSMF: "раньше выбирали из 5 российских вендоров и 5 иностранных, сейчас выбираем из 5 российских".

По нашему скромному мнению, наиболее популярными являются:
Naumen
Itilium
SimpleOne
ITSM 365
OTRS CE

Решение, которое мы сами используем и рекомендуем нашим клиентам - OTRS CE и его российский "форк" - Radiant ServiceDesk, решение уже в росреестре и сохранило все преимущества своего прародителя OTRS CE.

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

В зависимости от того, насколько структурированно хранятся данные и насколько зрелы процессы заказчика, миграция может занять от 3-4 недель до 6 месяцев. Очень сокращает время переезда правильный анонс о данном мероприятии для пользователей, включающий обучение/краткую инструкцию по обновлённому процессу.

Из наших кейсов можно привести пример одного из крупных производителей в области FMCG. У заказчика зрелость сервисных процессов и культура отправки обращений весьма высоки, задача стояла переделать "бэкэнд" сервис-деска на импортонезависимый стек с сохранение привычного UI.
В этом кейсе пользователи даже не заметили, что что-то изменилось: процесс остался прежним, UI не поменялся, на SLA никак не отразилось. Уложились в календарный месяц.

-

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

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

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

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

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

Если МФУ рассматривать как центр ввода(сканер) - вывода (копирование, печать), а еще принять во внимание, что может выводиться конфиденциальная информация. В этом случае утечка подобной информации может нанести вред работе компании.

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

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

Да, абсолютно верное замечание, к сожалению. Но есть и другой момент, назовем его "бессознательной защитой", когда МФУ работает автономно в кабинете, библиотеке и не подключено к сети вуза. В этом случае практически всегда устройство находится под присмотром ответственного, кто на нем печатает, сканирует и копирует. В случае работы в сети вузы уже несколько лет в России внедряют специальное ПО для обеспечения безопасной печати, как это давно делают коммерческие компании. Такая задача, увы, иногда решается точечно (т.е. защищать только МФУ и принтеры) в отрыве от инфраструктурной безопасности вуза.

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

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

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

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

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

Лайк за котиков))

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

Однозначно можно уже говорить, что российские платформы RPA очень активно развиваются и по некоторым функциональным параметрам превосходят зарубежные аналоги. Это вызвано активным спросом на решение прикладных задач у российских пользователей и мотивацией самих разработчиков. Объем рынка RPA в России с 2019 по 2021 год вырос в 10 раз, а к 2024 г. около 90% компаний будут "роботизированы" отечественными RPA (по данным экспертов компании «ИБА). Это наиболее активное направление развития ИТ в стране, а потребности в автоматизации уникальных задач, характерных для российских компаний (интеграции с 1С, обработка неструктурированных данных, распознавание кириллических символов и т.д), позволит укрепить фундамент развития ИТ-отрасли в целом.

У роботизации процессов большие перспективы.

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

В последнее время российские платформы RPA пытаются расширить функционал, делая упор на удобство проектирования (no-code, low-code) и интеграции со сторонними платформами. Многие решения, например, обзаводятся модулями распознавания текста (OCR), что значительно увеличивает роль в интеграции с ECM системами, а автономные решения OCR становятся на этом фоне уже менее значимыми. Или представьте, что чат-бот сможет обрабатывать вопросы не только в текстовом виде, но и выдавать решение голосом через интеграцию с голосовыми решениями. Перспектива будет определяться как запросами пользователей, так и технологическим ростом.

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

Да, немного не по теме статьи, но можно и здесь порассуждать. Не стоит обольщаться по поводу нейронных алгоритмов - это программное решение. Указанное решение неплохо справляется с многими задачами, но качество получаемого результата оставляет желать лучшего. Вот простой пример. Вы попросите написать вам код на python и вы получите листинг. Но python-скрипты в зависимости от версии имеют разный синтаксис. Если вы этого не знаете, то для вас полученный листинг может оказаться (с вашей точки зрения) нерабочим, а нейросеть вам дала рабочий листинг.

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

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

Такую информацию можно получить от вендора ПО.