Опыт работы с Nintex Workflow for SharePoint 2010

    imageПосле поста про автоматизацию заявок некоторые коллеги попросили меня поподробнее рассказать о workflow-редакторе Nintex и о тех подводных камнях, на которые можно наткнуться при его использовании.

    Я познакомилась с этим редактором ровно 2 года назад, когда ко мне подошел шеф и сказал: «Выучишь Nintex — поедешь в Казахстан». Для меня в тот период карьеры лучшей заманухи просто быть не могло. Надо сказать, что работа с этим редактором лично для меня все эти 3 года была скорее удовольствием и игрой, чем действительно работой.

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

    Несомненные преимущества перед стандартным workflow-дизайнером SharePoint


    1. Функционал. За последние 2 года я как аналитик занималась проектированием и внедрением более чем 20 корпоративных систем на SharePoint 2007/2010 различной сложности, функциональности и бизнес-направленности и из всего этого многообразия проектов я вспоминаю только один, где стандартную функциональность Nintex пришлось добавлять. Самое существенное отличие от стандартного функционала SharePoint состоит в огромном количестве логических операций с данными (от обычной проверки true/false до полноценной машины состояний, с помощью которой можно реализовать практически любую логику процесса).
    2. Простота освоения. Я аналитик, не программист. И для меня несомненным плюсом стала возможность моей работы с этим редактором. Меня наверняка поймут аналитики, которые пытаются достучаться до разработчиков своими идеями реализации хотелок заказчиков и натыкаются на фразу «Это нереализуемо», а также разработчики, к которым приходят аналитики и пытаются всучить нереализуемые требования. Я для себя эту проблему решила тем, что стала разрабатывать все workflow-процессы сама. Это экономит время мне, деньги заказчику и нервы моим коллегам.
    3. Работа в браузере. Также в силу своей профессии я в основном работаю на небольшом ноутбуке небольшой же производительности. Я стараюсь не устанавливать на него лишних программ, отъедающих оперативную память, потому что очень часто нужно зайти к заказчику в кабинет и сразу начать работать. Возможность проектирования рабочих процессов непосредственно в браузере для меня просто панацея.
    4. Возможность использования подхода GTD к построению процессов. С опытом внедрения корпоративных ИС я наткнулась на однин простой принцип: Лучшая информационная система — это та система, которую никто не замечает. Если у вас в компании внедрена система автоматизации, например, заявок, но большинство сотрудников не знает даже доступа к ней, но при этом в системе в год регистрируются сотни записей, то у Вас внедрена хорошая система. Когда пользователи имеют возможность регистрировать, комментировать, согласовывать записи через почту, это позволяет им не отрываясь от основных дел и не нервничая, делать свою работу хорошо. В связке Nintex+SharePoint большинство рабочих процессов можно реализовать так, что пользователю даже в систему заглядывать не придется.
    5. Добавление функционала. Если стандартного функционала все-таки не хватает, то Вы всегда сможете написать свои действия и использовать их в дальнейшем.

    Мои любимые функции Nintex


    1. Архитектура рабочих процессов. Nintex позволяет проектировать не только сложные с точки зрения функционала рабочие процессы, но и с точки зрения архитектуры системы, позволяя выносить на уровень узлов, типов содержимых как целые процессы, так и их фрагменты. Такой подход позволяет экономить на проектировании огромное количество человекочасов и делает развитие и изменение системы быстрым и безболезненным. Да и просто интересно строить правильную архитектуру рабочих процессов.
    2. LazyApproval. Самая востребованная на портальных проектах функция, которая позволяет согласовывать заявки напрямую из почтового уведомления. Работает она так: в центре администрирования задаются ключевые фразы для согласования/отклонения какого-то действия (ок, да, нет, пох, no, нет, нах...). Руководителю приходит письмо, содержащее максимальную информацию для принятия решения без входа в систему автоматизации. Он отвечает на письмо одной из ключевых фраз и забывает о системе до следующего письма.
    3. State Machine. Именно машина состояний коренным образом отличает этот редактор от всех своих основных конкурентов. Я делала рабочие процессы, которые содержали с десяток вложенный машин состояний и они работали и работают с отличной производительностью. Благодаря этой функции сделать процесс любой сложности стало делом минут, а не дней.
    4. Синхронизация с AD и профилями пользователей. Можно использовать данные о пользователях в любом месте рабочего процесса.
    5. Автоматически запускаемые рабочие процессы. По сравнению с версией редактора Nintex Workflow 2007, в версии 2010 значительно расширились возможности автозапуска рабочих процессов. К расписанию рабочих процессов и простому автозапуску при создании или изменении элементов списка SharePoint прибавился еще и условный запуск, который происходит при определенном изменении данных формы. Такой подход дает дополнительные баллы к производительности проектируемой системы.

    Собственно, подводные камни


    1. Фатальная дружба с IE. Как все знают, начиная с 2010 версии SharePoint активно поддерживает большинство принятых браузеров. Nintex не пошел по этому пути и разработку процессов призвал вести в Internet Explorer. Вы сможете пользоваться системами, разработанными с использованием Nintex, в остальных браузерах совершенно без проблем, но вести разработку новых процессов придется в IE. Так как дома я маковод, то рабочий бук приходится возить с собой домой, если нужно поработать вечерами. В остальных случаях я стараюсь не обращать внимание на то что постоянно приходится работать именно с Explorer. Кстати, именно поэтому статья без картинок.
    2. Стоимость. Еще одним огорчающим моментом является цена на серверную лицензию, от которой нередко округляются глаза у представителей малого бизнеса.
    3. Невозможен перезапуск процесса в том месте, где он упал. Допустим, в какой-то момент работы системы, на сервере начались какие-нибудь обновления или любой другой апокалипсис, который съел львиную долю оперативной памяти, и рабочий процесс отвалился по тайм-ауту. Так вот, перезапускать его придется с самого начала. Если в этом процессе уже произошли события с участием кучи пользователей, представьте их гнев, когда их нужно будет попросить «еще раз пересогласовать заявку». Эта проблема требует более правильного построения сложных процессов.
    4. Необходимость небольшой доработки на более высоком уровне.К сожалению, при проектировании сложных процессов не обошлось без доработок на уровне кода. Коснулись они в основном параметров отображения кнопок запуска процессов. Стандартный функционал уже не покрывает, например, такое требование, как «Функция отправки заявки ИТ на исполнение должна быть доступна только сотрудникам, включенным в группу Диспетчер»


    P.S. Автор надеется, что данная статья будет полезна тем, кто регулярно сталкивался с проблемами автоматизации бизнес-процессов на SharePoint. В Казахстан он (автор) так и не попал.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 13

      +2
      Я не хочу подробно рассказывать о возможностях этого продукта

      По-моему, Вы именно это и сделали.
        0
        Оригинальный мануал по этому продукту содержит около 1000 листов, если я не ошибаюсь. Поэтому, мне все же кажется, что тут еще есть к чему стремиться.
        0
        Статья интересная, но позволю заметить, что state machine на русский переводится обычно как «конечный автомат».
          +1
          :) спасибо за замечание. Так и есть. Правда по опыту общения с людьми, не знающими функций sm, замечено, что словосочетание «машина состояний» вызывает более адекватные ассоциации. Только поэтому использовала именно его
            +1
            А позвольте тогда поинтересоваться как будет обычно переводиться понятие из Cisco IVR 2.0 «Finite State Machine (FSM)»? :)
              0
              Я выбрасываю белый флаг:) Вы абсолютно правы:)
                +1
                Я думаю, точно так же. Во-первых, обычно, когда говорят state machine, подразумевают finite, а во-вторых, исторически в русском не сложилось двух разных понятий для этих моделей.

                Чтоб проверить, вы можете зайти на википедию, на статью state machine, и потом выбрать слева русскую версию статьи--вы окажетесь на статье «конечный автомат»)
              0
              Скажите, какова цена вопроса? На сайте можно сделать запрос на расценки в зависимости от кол-ва серверов (страшно не люблю такие вещи)
                0
                Базовая стоимость — от $3300 до $15000, в зависимости, от редакции на один сервер. Но, как и у MS, есть масса партнерских скидок.
                +2
                Опишу свои впечатления от работы с NW с позиции разработчика SharePoint:

                1) Функционал. В самом начале работы с NW, количество activity конечно впечатляет, но при дальнейшей разработке начинаешь натыкаться на неприятные ограничения.

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

                Из этой же серии — невозможность нормального задания due date при создании flexi task или, например, сборе рецензий. Или, еще нельзя задать необходимые разрешения на задачу: это означает, что у всех участников должны быть права, как минимум, contributor на весь список задач и все участники всегда будут видеть все задачи всех процессов.

                А с каким-то из недавних билдов, разработчики NW вообще отмочили — теперь Flexi task activity пишет ID созданного таска не при создании задачи, а при её выполнении. Приходится самому лезть в список задач (в параллельном действии, еще и подождав при этом минут 5, чтобы быть уверенным, что задача уже создана) и пытаться определить какая задача нам нужна.

                Хотя, надо отметить, что плагины на nintex connect, в половине случаев, помогают решить косяки разработчиков Nintex.

                2) Надёжность. Надо понимать, что Nintex — это всего лишь надстройка над SharePoint Workflow, т.е. вы наследуете все проблемы как SharePoint Workflow, так и WWF. Так, на одном из проектов, при большом количестве процессов, «удалось» словить мощный глюк, когда большое количество процессов тупо лочило все свои задачи и никто из участников не мог их сдвинуть. Проблема массу раз описана на форуме Nintex, ТП Nintex кивает на MS, ТП MS кивает на Nintex, заказчик в бешенстве.

                3) Стоимость. Согласен с автором, насчёт округляющихся глаз заказчика. Поэтому, как правило, покупка Nintex планируется под набор процессов.

                Если кому интересны аналоги Nintex — основные, это K2 BlackPoint (у них свой движок) и Datapolis Workbox 2010.
                  0
                  У меня дружба с flexi task так и не сложилась. Я использую практически на всех проектах обычные to-do task. В них можно добавить необходимые варианты выбора, а остальные поля скрыть или закрыть от редактирования. Единственный минус — тут не применишь лэйзик. При таком подходе Ваша проблема с id и с due date легко решаема.
                  Проблема с правами вообще общая для SharePoint и зачастую для реализации нормального защищенного доступа к данным требуется разрыв прав.
                  Насчет уязвимости согласна. Практика показала, что уязвимы очень большие процессы и автозапускаемые процессы. При нагрузке с ними бывают проблемы. Есть способы обойти некоторые тонкие места, но нужно смотреть на конкретный случай.
                  +1
                  А подскажите пожалуйста какие-нибудь конкретные характеристики, чтобы можно было быстро оценить пользу предлагаемого решения. Например, о цене вы говорите с загадочностью посвященных в тайное знание. Подскажите просто цену в рублях или долларах для какой-нибудь конфигурации. Еще вопрос: нагрузочные характеристики. Сколько «одновременно» работающих пользователей реально смогут работать без блокировки, описаной в комментарии. Можно ли подключать базу данных (сделать CRM систему на базе Shate Point). И неужели нет разделения прав пользователей?

                  Я понимаю, что все это можно прочитать в материалах Microsoft, но тем и ценно сообщество, что кто-то на практике сталкивается с продуктом и может буквально в паре строк описать его реальные достоинства, недостатки и ограничения. Заранее благодарен за ответ.
                    0
                    sergeypip, постараюсь раскрыть Вам тайные знания :) О цене — цена на серверную лицензию зависит от типа этой самой лицензии (Standard Edition, Enterprise Edition и Workgroup Edition) и действительно составляет от 3 до 15 тыс у.е. ИМХО, для автоматизации малого и среднего бизнеса достаточно Standard, но в Enterprise на мой взгляд больше возможностей для ведения статистики по процессам.

                    По нагрузке: все зависит от оборудования. SharePoint вообще любит хорошие сервера с хорошими же мощностями. Нагрузочные тесты показали, что при одновременной работе 100 человек, на системе, построенной на связке SharePoint+Nintex сервер с оперативкой 16 Гб справляется и процессы не встают в очередь.

                    По правам: в SharePoint права на уровне коллекции-сайта-библиотеки-списка распределяются отлично. Другое дело, когда Вам нужно в рамках одного списка разделять права на элементы. По умолчанию, чтобы создавать и редактировать элементы у пользователей должны быть определенные права (минимум на создание и резактирование). Но что делать, когда например появляются требования: доступ к созданным элементам должен иметь только автор. А это классическое требование для многих систем. В SharePoint есть возможность сделать настройку списка так, что читать и изменять элементы могут только авторы. Но в этом случае выдача дополнительных прав на элемент ничего не дает (я отправила свой элемент на согласования, а согласующий его все равно не видит). Для того, чтобы покрыть это требование, делается разрыв прав. При создании элемента права на него отбираются у всех пользователей и выдаются обратно автору, а по ходу обработки элемента и еще кому-то. Этот подход далеко не идеальный. Кстати, если у кого-то был более удачный опыт борьбы с этой проблемой — буду очень признательна обмену опытом.

                    CRM создать можно. Пользуюсь как раз CRM на SharePoint. Тут вопрос весь в том, какую базу будете подключать.

                  Only users with full accounts can post comments. Log in, please.