Sobre um cara

A história é real, vi tudo com meus próprios olhos.

Por vários anos, um cara, como muitos de vocês, trabalhou como programador. Por precaução, escreverei assim: “programador”. Porque ele era 1Snik, em uma empresa de produção fixa.

Antes experimentou diversas especialidades - 4 anos na França como programador, gerente de projetos, conseguiu completar 200 horas, ao mesmo tempo recebendo uma porcentagem do projeto, para gerenciamento e fazendo um pouco de vendas. Tentei desenvolver produtos por conta própria, fui chefe do departamento de TI de uma grande empresa com 6 mil pessoas, experimentei diferentes opções de utilização da minha profissão citável - programador 1C.

Mas todas estas posições eram um beco sem saída, principalmente em termos de rendimento. Naquela época, todos recebíamos aproximadamente o mesmo dinheiro e trabalhávamos nas mesmas condições.

Esse cara estava se perguntando como poderia ganhar mais dinheiro sem vender ou criar seu próprio negócio.

Ele se considerava um cara inteligente e decidiu procurar um nicho na empresa onde trabalhava. Esse nicho tinha que ser algo especial, não ocupado por ninguém. E eu queria que a própria empresa quisesse pagar para uma pessoa desse nicho, para que não houvesse necessidade de enganar ninguém ou trapacear em nada. Para atingir esse objetivo: uma pessoa nesta posição precisa receber muito dinheiro. Um excêntrico, em uma palavra.

A busca durou pouco. Na empresa onde esse cara trabalhava, havia um nicho totalmente gratuito que poderia ser chamado de “colocar ordem nos processos de negócios”. Toda empresa tem muitos problemas. Algo sempre não funciona e não há ninguém que venha consertar o processo de negócio. Por isso, decidiu tentar ser um especialista que pode ajudar o proprietário a resolver seus problemas nos processos de negócios.

Na época, ele trabalhava na empresa há seis meses e recebia o salário médio do mercado. Não havia nada a perder, especialmente porque ele poderia facilmente encontrar o mesmo emprego em uma semana. Em geral, esse cara decidiu que nada de ruim aconteceria se de repente nada desse certo e ele fosse demitido.

Ele criou coragem e foi até o dono. Sugeri que ele melhorasse o processo mais problemático do negócio. Naquela época era contabilidade de armazém. Agora todos que trabalham nesta empresa têm até vergonha de lembrar desses problemas, mas os inventários, que eram realizados trimestralmente, apresentavam discrepâncias entre o sistema contábil e os saldos reais de dezenas de por cento. E em custo, em quantidade e em número de cargos. Foi um desastre. Na verdade, a empresa tinha os saldos corretos no sistema contábil apenas quatro vezes por ano – no dia seguinte à contagem do estoque. Nosso cara começou a colocar esse processo em ordem.

O cara concordou com o proprietário que ele deveria reduzir pela metade os desvios dos resultados do estoque. Além disso, o proprietário não tinha nada de especial a perder, pois antes do nosso herói vários trabalhadores já haviam feito tentativas de consertar tudo e, em geral, a tarefa era considerada praticamente insolúvel. Tudo isso despertou muito o interesse, porque se tudo desse certo, o cara automaticamente se tornaria uma pessoa que sabe colocar as coisas em ordem e resolver problemas insolúveis.

Assim, ele se deparou com a tarefa: reduzir os desvios com base nos resultados do estoque em 2 vezes em um ano. No início do projeto ele não tinha ideia de como conseguir isso, mas entendeu que a contabilidade do armazém é uma coisa simples, então ele ainda seria capaz de fazer algo útil. Além disso, reduzir os desvios de dezenas de por cento para uma dezenas de por cento não parece ser tão difícil. Qualquer pessoa que já trabalhou em consultoria ou atividades similares entende que a maioria dos problemas de processos pode ser resolvida com passos bastante simples.

De janeiro a maio, ele preparou, automatizou um pouco, reescreveu o processo de negócios de contabilidade do armazém, mudou o fluxo de trabalho dos lojistas, contadores e geralmente refez todo o sistema, sem mostrar ou contar nada a ninguém. Em maio, ele distribuiu novas instruções a todos e, após o primeiro inventário do ano, começou uma nova vida - trabalhando de acordo com suas regras. Para observar os resultados, futuramente a empresa passou a realizar inventários com maior frequência - uma vez a cada dois meses. Os primeiros resultados já foram positivos e, no final do ano, os desvios em relação aos resultados da auditoria tinham caído para uma fracção de um por cento.

O sucesso foi colossal, mas não se podia acreditar na sua sustentabilidade. O próprio cara duvidava que o resultado fosse preservado se ele se afastasse e parasse de observar o processo. Mesmo assim deu resultado, e o cara recebeu tudo o que combinou com o dono. Então, depois de vários anos, a estabilidade do resultado foi confirmada - durante vários anos os desvios permaneceram dentro de 1%.

Então ele decidiu repetir o experimento e sugeriu que o proprietário melhorasse outro processo problemático - o abastecimento. Houve escassez que não nos permitiu expedir os volumes que os nossos clientes desejavam. Concordamos que dentro de um ano os déficits seriam reduzidos pela metade, e o cara também concluiria de 10 a 15 projetos relacionados a 1C - para automatizar vários processos de negócios e outras heresias.

No segundo ano, tudo foi novamente concluído com sucesso, os défices diminuíram mais de 2 vezes, todos os projetos de TI foram concluídos com sucesso.

Como o salário já atendia plenamente todas as necessidades daquele cara com dois anos de antecedência, ele resolveu se acalmar um pouco, se acalmar e sentar em um lugar aconchegante e aconchegante que ele havia criado para si.

Como foi? Formalmente, ele era o diretor de TI. Mas quem ele realmente era é difícil de entender. Afinal, o que faz um diretor de TI? Via de regra, ele administra a infraestrutura de TI, gerencia administradores de sistemas, implementa sistema ERP e participa de reuniões do conselho de administração.

E esse cara tinha uma das principais responsabilidades de participar dos processos de mudança, e principalmente - geração, iniciação desses processos, busca e proposta de soluções, aplicação de novas técnicas de gestão, exame das mudanças propostas, análise da eficácia de outras funções e divisões e, por fim, participação direta no desenvolvimento estratégico do empreendimento, até o desenvolvimento independente de um plano estratégico para toda a empresa.

Ele recebeu carta branca. Ele poderia comparecer a qualquer reunião onde não tivesse tido acesso anteriormente. Fiquei ali sentado com um bloco de notas, escrevendo algo ou apenas ouvindo. Ele raramente falava. Então ele começou a brincar no telefone, alegando que a memória associativa funciona melhor assim.

Na reunião, ele raramente revelava algo útil. Ele saiu, pensou, depois chegou uma carta - seja com críticas, seja com opinião, seja com sugestões, seja com a descrição das soluções que já havia aplicado.

Porém, com mais frequência, ele mesmo convocava reuniões. Encontrei um problema, encontrei soluções, identifiquei as partes interessadas e trouxe todos para a reunião. E então - da melhor maneira que pôde. Ele convenceu, motivou, provou, argumentou, alcançou.

Extraoficialmente, ele era considerado a terceira pessoa da empresa, depois do proprietário e do diretor. Claro, ele enfureceu terrivelmente todas as “pessoas da empresa”, começando pelo número 4. Principalmente com seus jeans rasgados e camisetas brilhantes, e também com seu tempo como dono.

O proprietário deu-lhe 1 hora por dia. Diariamente. Conversaram, discutiram problemas, soluções, novos negócios, áreas de desenvolvimento, indicadores e eficiência, desenvolvimento pessoal, livros e simplesmente a vida.

Mas esse cara era estranho. É tipo, sente-se e seja feliz, a vida é boa. Mas não. Ele decidiu refletir.

Ele se perguntou: por que funcionou para ele e outros não? O proprietário também o pressionou: disse que queria que outros também pudessem colocar a ordem, porque são muitos gestores, eles, via de regra, estão engajados na gestão operacional e no planejamento estratégico, mas praticamente ninguém está engajado em mudanças sistêmicas em seus processos. Pode estar escrito na descrição do trabalho que eles deveriam acelerar o processo e aumentar sua eficiência, mas na verdade ninguém está fazendo isso. Por que é que? O cara também se interessou em saber o porquê e foi conversar com todos esses gestores.

Ele procurou o vice-diretor de qualidade e sugeriu a introdução de gráficos de controle de Shewhart para que os produtos fossem melhores que os japoneses. Mas descobriu-se que o colega não sabia o que eram gráficos de controle de Shewhart, o que era controle estatístico de processos e só tinha ouvido falar do uso do ciclo de Deming na gestão da qualidade. OK…

Ele procurou outro vice-diretor e sugeriu a introdução do controle. Mas também não encontrei apoio aqui. Um pouco mais tarde, ele conheceu o gerenciamento de fronteiras (gestão de limites) e sugeriu que todos os diretores-adjuntos implementassem a parte sistêmica dessa metodologia para melhorar os processos. Mas não importa o quanto nosso cara falasse, ninguém queria realmente se aprofundar no que se tratava. Talvez eles não estivessem interessados ​​ou fosse muito difícil. Mas, na verdade, ninguém percebeu.

Em geral, ele falou sobre tudo o que sabia e utilizava na empresa. Mas ninguém o entendeu. Eles ainda não entendem por que, por exemplo, tudo foi corrigido na contabilidade do armazém e o que o controle e a gestão de fronteiras têm a ver com isso.

Por último, ele alcançou seus programadores - a equipe incluía 3 pessoas. Ele falou sobre gestão de limites, sobre controle, sobre gestão de qualidade, sobre ágil e scrum... E surpreendentemente, eles entenderam tudo, e conseguiram até discutir de alguma forma com ele, inclusive sutilezas técnicas e metodológicas. Eles entenderam por que os projetos de armazenamento e abastecimento deram certo. E então o cara percebeu: na verdade, os programadores vão salvar o mundo.

Os programadores, percebeu ele, são os únicos que conseguem compreender os processos de negócios normalmente, com os detalhes necessários.

Por que eles? Na verdade, ele nunca encontrou uma resposta clara. Formulei apenas dicas de tese.

Em primeiro lugar, os programadores conhecem as áreas de negócio e as conhecem melhor do que todas as outras pessoas na empresa.

Além disso, os programadores realmente entendem o que é um algoritmo de processo. Isto é importante porque os processos de negócios são algoritmos e os elementos neles contidos podem simplesmente não ser consistentes. Por exemplo, no processo de compras em que o cara estava trabalhando, o primeiro passo era criar um plano de compras anual e o segundo eram as compras diárias. Essas etapas estão interligadas por uma conexão direta, ou seja, presume-se que as pessoas devem trabalhar de acordo com esse algoritmo - traçar um plano anual de compras e executar imediatamente a solicitação. O plano anual de aquisições é elaborado uma vez por ano e as candidaturas são recebidas 50 vezes por dia. É aqui que o algoritmo termina e você precisa trabalhar nisso. Na verdade, argumentou ele, para os programadores, o conhecimento de algoritmos é uma vantagem competitiva, porque qualquer pessoa que não esteja familiarizada com eles simplesmente não entende como um processo de negócios deve funcionar e como pode ser representado.

Outra vantagem dos programadores, segundo o cara, é que eles têm bastante tempo livre. Todos nós entendemos como um programador pode gastar três vezes mais tempo em uma tarefa do que realmente requer, e poucos perceberão. Isso, novamente, é uma vantagem competitiva, pois para colocar algum processo de negócio em ordem é preciso ter muito tempo livre - pensar, observar, estudar e experimentar.

A maioria dos gestores, segundo o cara, não tem esse tempo livre e se orgulha disso. Embora na verdade isso signifique que uma pessoa não pode se tornar eficaz porque não tem tempo para melhorar a eficiência - um círculo vicioso. Na nossa cultura está na moda estar ocupado, então tudo permanece igual. E para nós, programadores, isso é uma vantagem. Podemos encontrar tempo livre e pensar em tudo.

Os programadores, disse ele, podem mudar rapidamente um sistema de informação. Isto não se aplica a todas as empresas, mas onde quer que ele trabalhasse, ele poderia fazer as modificações que quisesse. Principalmente se não dizem respeito ao trabalho de ninguém. Por exemplo, ele poderia lançar um sistema que mediria secretamente as ações dos usuários e depois usaria essas informações para analisar a eficiência do mesmo departamento de contabilidade e rastrear os custos da contabilidade.

E a última coisa que me lembro das palavras dele é que os programadores têm acesso a uma grande quantidade de informação, porque... ter acesso administrativo ao sistema. Portanto, eles podem usar essas informações em suas análises. Ninguém mais em uma fábrica regular possui esse recurso.

E então ele foi embora. Durante as duas semanas de detenção exigidas, obrigámo-lo a partilhar a sua experiência porque queríamos continuar o trabalho que estava a fazer. Bem, sua posição ficou vaga.

Ao longo de vários dias, sentaram-no numa cadeira, ligaram a câmera e gravaram seus monólogos. Eles pediram para nos contar sobre todos os projetos concluídos, métodos, abordagens, sucessos e fracassos, causas e efeitos, retratos de gestores, etc. Não houve restrições especiais, porque Eles não sabiam o que estava acontecendo em sua cabeça.

Os monólogos, é claro, eram em sua maioria bobagens e risadas - ele estava de ótimo humor, porque estava saindo do sertão para São Petersburgo. Onde você deveria trabalhar em São Petersburgo? Para a Gazprom, é claro.

Mas conseguimos extrair algo útil de seus monólogos. Vou te contar o que me lembro.

Então, as recomendações desse cara. Para quem quer tentar colocar ordem nos processos de negócio.

Para fazer esse tipo de trabalho, em primeiro lugar, é necessário ter um certo nível de “congelamento”. Você não deve ter medo de perder o emprego, não ter medo de correr riscos, não ter medo de conflitos com colegas. Foi fácil para ele, pois iniciou sua jornada quando trabalhava na empresa há apenas seis meses, não tinha tempo de entrar em contato com ninguém e nem pretendia fazê-lo. Ele entendeu que as pessoas vêm e vão, mas seus próprios resultados e a avaliação deles pelo empresário são importantes para ele. Se seus colegas o tratavam bem ou mal, pouco lhe importava na época.

O segundo ponto é que para fazer esse trabalho com eficácia, infelizmente, você terá que estudar. Mas estude não para um MBA, nem em cursos, nem em institutos, mas por conta própria. Por exemplo, no seu primeiro projeto, um projeto de armazém, ele agiu de forma intuitiva, não sabia nada, apenas o que era “gestão da qualidade”.

Quando ele começou a ler a literatura sobre quais métodos existiam para aumentar a eficiência, ele descobriu as tecnologias que usava. O cara aplicou intuitivamente, mas acontece que não foi invenção dele, tudo já estava escrito há muito tempo. Mas ele gastou tempo, e muito mais do que se tivesse lido imediatamente o livro certo. Aqui só é importante entender que quando você estuda uma técnica específica, nenhuma delas, mesmo a mais avançada, resolverá completamente todos os problemas de um processo de negócio.

O segundo truque é que quanto mais técnicas você conhecer, melhor. Por exemplo, no Japão antigo viveu Miyamoto Musashi, um dos espadachins mais famosos, autor do estilo de duas espadas. Ele estudou em alguma escola com algum mestre, depois viajou pelo Japão, lutou com caras diferentes. Se o cara fosse mais forte, a jornada parava por um tempo e Musashi virava estudante. Como resultado, ao longo de vários anos adquiriu as competências de diversas práticas de diferentes mestres e formou a sua própria escola, acrescentando algo de sua autoria. Como resultado, ele alcançou uma habilidade única. É a mesma coisa aqui.

Você pode, é claro, atuar como consultor de negócios. Em geral, eles são ótimos caras. Mas, via de regra, eles introduzem algum tipo de metodologia e implementam a metodologia errada que o negócio precisa. Também tivemos situações tão tristes: ninguém sabe como resolver o problema e ninguém quer pensar em como resolvê-lo. Começamos a pesquisar na Internet ou ligamos para um consultor e perguntamos o que pode nos ajudar. O consultor pensa e diz que precisamos introduzir a teoria das restrições. Pagamos pela recomendação, gastamos dinheiro na implementação, mas os resultados são zero.

Por que isso acontece? Porque disse o consultor, estamos introduzindo tal e tal sistema e todos concordaram com ele. Ótimo, mas uma metodologia não cobre todos os problemas de um único processo de negócio, especialmente se os pré-requisitos iniciais - os nossos e os necessários para implementar a metodologia - não coincidirem.

Na prática que o cara recomenda, você precisa pegar o que há de melhor e implementar o que há de melhor. Não considere os métodos inteiramente, mas sim seus principais recursos, características e práticas. E o mais importante é entender a essência.

Tomemos, disse ele, por exemplo, Scrum ou Agile. Em seus monólogos, o cara repetiu diversas vezes que nem todo mundo entende bem a essência do Scrum. Ele também leu o livro de Jeff Sutherland, que algumas pessoas consideram uma “leitura leve”. Pareceu-lhe uma leitura profunda, pois um dos princípios fundamentais do Scrum é a gestão da qualidade, isso está escrito diretamente no livro.

Fala sobre a Toyota Production, sobre como Jeff Sutherland mostrou o Scrum no Japão, como ele se enraizou lá e quão próximo estava de sua filosofia. E Sutherland falou sobre a importância do papel do Scrum Master, sobre o ciclo de Deming. O papel do Scrum Master é acelerar constantemente o processo. Tudo o mais que está no Scrum – entrega faseada, satisfação do cliente, uma lista clara de trabalho para o período do sprint – também é importante, mas tudo isso deve acontecer cada vez mais rápido. A velocidade de trabalho deve aumentar constantemente nas unidades em que é medida.

Talvez seja uma questão de tradução, porque nosso livro foi traduzido como “Scrum - um método revolucionário de gerenciamento de projetos”, e se o título em inglês for traduzido literalmente, resultará: “Scrum - o dobro na metade do tempo” , isto é, mesmo em O nome refere-se à velocidade como uma função chave do Scrum.

Quando esse cara implementou o Scrum, a velocidade dobrou no primeiro mês sem nenhuma mudança significativa. Ele encontrou pontos para mudança e modificou o próprio Scrum para fazê-lo funcionar muito mais rápido. A única coisa que escrevem na Internet é que se depararam com a pergunta: “Dobramos a velocidade, só falta entender o que estamos fazendo com tanta velocidade?” Mas esta é uma área completamente diferente...

Ele também recomendou pessoalmente várias técnicas. Ele os chamou de fundamentais e fundamentais.

O primeiro é o gerenciamento de limites.

Eles ensinam em Skolkovo, segundo o cara não tem outros livros e materiais. De alguma forma, ele teve a sorte de assistir a uma palestra de um professor de Harvard que prega o gerenciamento de fronteiras e também de ler vários artigos na Harvard Business Review sobre o trabalho de Eric Trist.

O gerenciamento de limites diz que você precisa ser capaz de ver os limites e trabalhar com eles. As fronteiras são muitas, estão por todo o lado - entre departamentos, entre diferentes tipos de trabalho, entre funções, entre trabalho operacional e analítico. O conhecimento da gestão de fronteiras não revela quaisquer verdades superiores, mas permite-nos ver a realidade sob uma luz ligeiramente diferente - através do prisma das fronteiras. E, consequentemente, gerencie-os - erga-os quando necessário e remova-os onde estiverem no caminho.

Mas na maioria das vezes o cara falava sobre controle. Ele apenas tinha algum tipo de peculiaridade sobre esse assunto.

Controlar, em suma, é uma gestão baseada em números. Aqui, disse ele, cada parte da definição é importante – tanto “gestão” como “baseada em” e “números”.

Nós, disse ele, somos ruins em todos os três componentes do controle. Especialmente considerando que eles estão intimamente interligados entre si e com outras partes do sistema empresarial.

A primeira coisa ruim são os números. São poucos e de baixa qualidade.

Em seguida, retiramos uma parte significativa dos números do sistema de informação 1C. Portanto, a qualidade dos números em 1C, como ele afirmou, não é boa. No mínimo, devido à capacidade de alterar dados retroativamente.

É claro que isso não é culpa dos desenvolvedores 1C - eles apenas levam em consideração as exigências do mercado e a mentalidade da contabilidade nacional. Mas para fins de controle, é melhor mudar os princípios do trabalho 1C com dados em uma empresa específica.

Além disso, os números de 1C, segundo ele, passam por processamento semimanual, no Excel, por exemplo. Tal processamento também não agrega qualidade aos dados, bem como eficiência.

No final, outra pessoa verifica novamente o relatório final para não enviar acidentalmente números com erros ao gestor. Com isso, os números chegam ao destinatário bonitos, verificados, mas muito atrasados. Geralmente - após o término do período (mês, semana, etc.).

E aqui, disse ele, tudo é muito simples. Se os números de janeiro chegaram até você em fevereiro, você não poderá mais gerenciar as atividades de janeiro. Porque janeiro já acabou.

E se os números são baseados na contabilidade, e a empresa é a mais comum, com apresentação trimestral de IVA, então o seu gestor recebe valores relativamente adequados uma vez por trimestre.

O resto está claro. Você recebe números uma vez por mês - você tem a oportunidade de gerenciar por números (ou seja, controle) 12 vezes por ano. Se você pratica relatórios trimestrais, você os gerencia quatro vezes por ano. Mais um bônus - relatórios anuais. Dirija mais uma vez.

No resto do tempo, o controle geralmente é realizado às cegas.

Quando (e se) os números aparecerem, então o segundo problema entra em jogo – como gerir com base nos números? Eu não poderia concordar com este ponto de seu raciocínio.

O cara argumentou que se o gerente não tivesse os números antes, a aparência deles causaria um efeito surpreendente. Ele vai olhar e torcer os números para um lado e para outro, chamar as pessoas no tapete, exigir explicações e investigações. Depois de brincar com números, fazer análises e prometer ameaçadoramente a todos os funcionários que “agora não vou me livrar de vocês”, o gerente rapidamente se acalmará e desistirá desse assunto. Pare de usar a ferramenta. Mas os problemas permanecerão.

Isso acontece, disse ele, devido à insuficiência de competências gerenciais. No controle, antes de tudo. O gestor simplesmente não sabe o que fazer com esses números. O que сfazer - sabe o que fazer - não. Fazer é o que está escrito acima (brigar, brincar). Fazer é um processo de negócios diário.

Ele argumentou que tudo é muito simples: o digital deve passar a fazer parte do processo de negócios. No processo de negócios deve ficar claramente claro: quem deve fazer o quê e quando se os números se desviarem da norma (quaisquer opções - acima da fronteira, abaixo da fronteira, ultrapassando o corredor, a presença de uma tendência, o não cumprimento dos quantil, etc.)

E assim traçou o dilema principal: o número existe, deveria fazer parte do sistema empresarial para aumentar a eficiência da gestão, mas... isso não está acontecendo. Por que?

Porque o líder russo não abrirá mão de uma parte do seu poder a um concorrente.

Os concorrentes do gerente russo - um processo de negócios funcional e de alta qualidade, motivação bem pensada e mutuamente benéfica e automação adequada - infelizmente, deixarão o gerente sem emprego.

Meio absurdo, você não concorda? Principalmente sobre líderes. Ok, eu te disse, você decide por si mesmo.

Um pouco menos, mas ainda muito, na minha opinião, ele falou sobre Scrum.

Certifique-se, eu disse, de ler e experimentar o Scrum na prática. Se, diz ele, você leu, mas ainda não experimentou, considere-se um ignorante. É melhor ler um livro, por exemplo de Sutherland, do que artigos e todo tipo de guias (que diabos?) na Internet.

Scrum, disse ele, só pode ser aprendido através da prática e com medições obrigatórias da quantidade de trabalho realizado. Experimente pessoalmente as duas funções mais importantes - Product Owner e Scrum Master.

É especialmente importante, segundo o cara, vivenciar na prática o papel de um Scrum Master, quando é possível aumentar o volume de tarefas concluídas por sprint sem aumentar os recursos e o custo do sprint.

Bem, no topo dele estava o TOS (teoria das limitações do sistema).

Esses, segundo o cara, são os princípios básicos e fundamentais para aumentar a eficiência que podem ser aplicados em quase todas as áreas, em qualquer processo de negócio e sistema de negócio como um todo.

Quando ele descobriu que não conhecíamos os TOS, ele parou de nos contar. Acrescentou apenas que não nos privaria do prazer de ler os livros de Eliyahu Goldratt. Ele deu uma recomendação semelhante ao Scrum – leia e experimente. Tipo, não importa em que posição você ocupe, não importa o trabalho que você faça, há um lugar para aumentar a eficiência usando métodos TOC.

Aí seu acervo de técnicas aparentemente secou e ele disse: misture os princípios para criar soluções aplicadas em uma situação específica.

Esta, diz ele, é a principal recomendação, a chave do sucesso. Compreenda os princípios, a essência e crie soluções de aplicativos exclusivas - processos de negócios e sistemas de negócios.

Então ele tentou se lembrar de alguma citação e, no final, teve que entrar na Internet. Acabou sendo uma citação do artigo “Standing on the Shoulders of Giants”, de Eliyahu Goldratt:

“Há uma diferença entre as soluções aplicadas (aplicações) e os conceitos fundamentais em que essas soluções se baseiam. Os conceitos são gerais; as soluções aplicadas são a adaptação de conceitos a um ambiente específico. Como já vimos, tal adaptação não é simples e requer o desenvolvimento de determinados elementos da solução. Devemos lembrar que uma solução de aplicação é baseada em suposições iniciais (às vezes ocultas) sobre um ambiente específico. Não se deve esperar que esta solução de aplicação funcione em um ambiente para o qual as suposições não sejam corretas.”

Ele disse que o trabalho de um programador e de um “melhorador de processos de negócios” é muito semelhante. E esquerda.

Fonte: habr.com