Если вы хотите добиться UI отзывчивости вашего iOS приложения, выполняя такие затратные по времени куски кода, как загрузка данных из сети или обработка изображений, то вам нужно использовать продвинутые паттерны, связанные с многопоточностью (сoncurrency), иначе работа вашего пользовательского интерфейса (UI) начнет сильно замедляться и даже может привести к полной его «заморозке». Вам нужно убрать ресурсо-затратные задачи с main thread (главного потока), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI).

В текущей версии Swift 3 и ближайшей Swift 4 (осень 2017) это можно сделать двумя способами, которые пока не связаны с встроенными языковыми конструкциями Swift, начало реализации которых будет только в Swift 5 (конец 2018).

Один из них использует GCD (Grand Central Dispatch) и ему посвящена предыдущая статья. В этой статье мы покажем, как достичь отзывчивости UI в iOS приложениях с помощью таких абстрактных понятий, как операция Operation и очередь операций OperationQueue. Мы также покажем в чем различие этих двух подходов и какой из них в каких ситуациях лучше использовать.

Код для этой статьи можно посмотреть на Github.

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

Вторая часть статьи.
Большинство современных вычислительных машин, будь то суперкомпьютер Fujitsu K, обычная персоналка или даже калькулятор, объединяет общий принцип работы, а именно модель вычислений, основанная на потоке управления (Controlflow). Однако, эта модель не является единственно возможной. В некотором роде ее противоположностью является модель вычислений, управляемая потоком данных, или просто Dataflow. О ней я и хочу сейчас рассказать.

Многие из нас занимаются изучением английского языка, потому что в сфере ИТ большинство документации, форумов и просто полезной информации изложено на универсальном языке – английском. И каждый находит для себя свой подход к обучению: кто-то идет к своей цели постепенно, планомерно, кто-то более экспрессно и выборочно. В самом деле, в Интернете вы найдете более 9000 методик, о том, как эффективно и быстро выучить язык самому. В языковой школе вам предложат несколько целевых программ: от «разговорных навыков делового человека» до «целенаправленной сдачи TOEFL». Чего же нового хочу я предложить? Мы поговорим о «фоновом» изучении языка. Цель моего поста – поделиться с вами способами изучения языка, которые я использовал. Постараюсь показать концепцию в целом, который каждый из вас сможет интегрировать в свой способ познания языка.

Я вот не поленился и обзвонил несколько руководителей компаний, моих клиентов. На предмет — знают ли они что такое «система поддержки принятия решений». Не знают. Однако, все ей пользуются.

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

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

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

За последние полгода я натестировался ERP систем по полной программе. Участвовал в обзоре российского рынка ERP систем. Интересные вещи всплывали, признаюсь я вам. И ладно, если бы эти интересности всплыли, если бы я во время обзора представлялся от имени редакции издания, которое этот обзор и проводило. Но мы намеренно сделали так, что представлялся я от имени совершенно реального клиента. То есть побывал в шкуре самого натурального клиента и увидел все своими глазами. Подробности обзора рассказывать не буду, их можно будет почитать на страницах издания (как выйдет обзор, выложу пост). Вывод прост – надо быть готовым к тому, что тебя будут пытаться «немножко обмануть». Попробую дать некоторые рекомендации, чтобы этого не случилось.

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

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

Вторую часть, пожалуй, начну с ответов на некоторые вопросы по прошлой части. Некоторые читатели обвинили меня в бессистемности, сказав, что вот, мол, непонятно чем тут занимается, какой-то НДС в бланках смотрит. Нет, чтобы думать о более высоких материях. Понимаете, мне эти высокие теории и материи… Я внедрением уже 10 лет как занимаюсь и хочу, чтобы рано или поздно любое внедрение стало простым и формализованным процессом. Ни у кого не возникает вопрос, когда нужно взять и настроить сеть, потому что ее просто берут и настраивают, и всем понятно, как именно это нужно делать. Вот и при внедрении ERP нужно стремиться к тому же.

У нас ежемесячно выходит новая версия. Она проходит жесткий тестинг перед тем, как ее поставят клиентам. Это такая инструкция на 6 листах. И версия не выходит пока все не будет тип-топ. Тестер почти не думает, просто тестирует по инструкции и все. Проколы, конечно, случаются, но не часто, да и то мелкие. После каждого прокола карта тестирования дорабатывается. Вот и то тестирование, о котором я тут толкую, тоже должно проходить по аналогичному принципу. Есть ряд простых, мелких, но жизненноважных тестов. Просто делаешь их и смотришь на результат. Прошло тестирование успешно, значит можно продолжать разговор о внедрении, разработке ТЗ и о более высоких материях. Не прошло тестирование – до свидания. Все!

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

Вот есть рынок ERP-систем. Большой, вроде как растущий рынок (сейчас, правда, очень сомнительно, что он растет). Ежегодно какие-то умные дядьки его оценивают, публикуют страшные для восприятия цифры. На рынке есть некое количество неких программных продуктов, количество которых поддается счету. Это и есть продукты этого рынка. А что могут эти продукты?

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

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

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

После вот этого поста о внедрении ERP систем, я решил тоже написать по этому поводу. Человек, лично руководивший хотя бы двумя-тремя проектами, никогда так не напишет. Этот пост я встречал как-то в жж в качестве комментария. Но одно дело комментарий и совсем другое дело – пост. Все случаи свалены в одну кучу.

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

Я попытаюсь раскрыть эту проблематику более полно и точно.

Да, понятно, что в России с успешным внедрением ERP систем дела обстоят не так, как на Западе. Хотя, и в Датском Королевстве, уверен, не все ладно.

В Россию пришел еще один производитель ERP-систем. Компания Sage. Событие положительное, потому как конкуренция. Но возникает впечатление, что Sage пришел в Россию явно с опаской. Прямого представительства в России нет, работают через единственного партнера — компанию Energy Consalting. И еще целый ряд интересных нюансов.

Есть ли перспективы у этого продукта при таком подходе? Попробуем разобраться.

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

Компания Digital Security провела исследование безопасности ERP систем SAP и Oracle. Результаты исследования неутешительны для вышеназванных производителей. Однако Digital Security обнаружила всего лишь верхушку айсберга, не зная, как оно там в деталях, в производстве, так сказать. Я же хочу рассказать о причинах, по которым клиенты вышеназванных ERP-систем «живут» с этими проблемами почти десятилетиями и почему-то их не решают.

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

Этот вопрос возникает на повестке дня практически во всех компаниях, внедривших CRM-систему.

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

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

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

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

Меня пригласили на встречу в компанию, которая десять (!!!) лет своими силами разрабатывала программный продукт для управления бизнес процессами (язык не поворачивается этот продукт назвать erp системой).
И вот по истечении десяти лет руководство компании понимает, что… ничего не понимает. В буквальном смысле слова. Программный продукт прекрасно решает вопросы, связанные с логистикой. Иными словами все вопросы, от момента получения заказа до момент вручения груза клиенту, решены весьма и весьма неплохо. Действительно неплохо. И все. Больше ничего.

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

Есть такие люди, они очень любят чинить автомобили. Покупают, а потом всегда там чего-то чинят. Они всегда найдут, что там починить. А потом эта машина попросту ездить перестает от этих «починок». И страдальца буксируют в сервис. В реанимацию так сказать.

Open source ERP системы тоже любят примерно такие же «кулибины». Ну, вот любят они сам процесс «созидания» и все тут.

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

Надо стараться придерживаться трех простых правил, если вы хотите успешного внедрения.

Минимум разработки

Как это не странно, но именно разработка программного обеспечения — самое слабое место ERP-проектов. Какое бы красивое ТЗ ты не написал, ты никогда заранее не знаешь, будет это работать в реальной жизни или нет. Хорошие программы пишутся не с первого раза. Чем больше в проекте разработки, тем выше риски неудачи. Разработка ПО — это как создание дизайна. Вроде обо всем договорился, а когда получил результат — понимаешь, что не то. Разумеется есть только один способ снизить объем разработки — взять продукт, где уже по максимуму разработано и работает то, что тебе нужно.

Как посчитать экономическую эффективность от внедрения ERP-системы. Таким вопросом задаются очень многие. Изложу свою точку зрения.

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

«Давай внедрим то, давай внедрим это». Предложения внедрить что-то звучат для него регулярно. Оно и понятно. Инициатива, так сказать. Однако очень скоро он приучил всех, что первый вопрос, который сотрудник услышит в ответ на свое предложение что-то внедрить, будет звучать так: «Насколько компания будет больше зарабатывать или насколько меньше она будет тратить, если мы сделаем это?»

К слову сказать, на это понадобилось лет шесть изысканий.

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

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

Свои изыскания в этой части мы начали году в 2006-м, полагая, что лучшее решение для производства — это MRP. В 2010-м году, после некоторых опытов по внедрению, мы поняли, что MRP не ведет к увеличению эффективности. Количество заказов, произведенных точно в срок, не увеличивается, запасы не уменьшаются, скорость производства не растет. А зачастую даже наоборот. Я написал статью об этом. Довольно эмоциональную. Видимо серьезно задев тех, кто зарабатывает на внедрении MRP. Но ведь целью внедрения любой системы менеджмента должно быть увеличение эффективности, не так ли? Многие об этом забывают, как, впрочем, и о том, что цель бизнеса – зарабатывать деньги. Поэтому внедрение MRP чаще всего превращается просто в проект по внедрению MRP, а в не в проект по улучшению эффективности производства.