A história é real, eu vi tudo com meus próprios olhos.
Por vários anos, um rapaz, assim como muitos de vocês, trabalhou como programador. Para esclarecer: "programador". Porque ele era um especialista em 1C, fixado em uma empresa de produção.
Antes disso, ele tentou várias profissões — 4 anos como programador em uma consultoria, gerente de projetos, conseguindo fechar 200 horas, enquanto recebia uma porcentagem do projeto por gerência e um pouco se dedicando a vendas. Tentou desenvolver produtos de forma independente, foi chefe do departamento de TI em uma grande empresa com 6 mil funcionários, experimentou diferentes formas de aplicar sua profissão de programador 1C.
Mas todos esses cargos eram um tanto sem futuro, principalmente por causa da renda. Todos nós naquela época recebíamos mais ou menos o mesmo salário e trabalhávamos nas mesmas condições.
Esse garoto ficou curioso para saber como poderia ganhar mais dinheiro, sem se envolver em vendas ou criar seu próprio negócio.
Ele se achou inteligente e decidiu encontrar um nicho na empresa onde trabalhava. Esse nicho deveria ser algo especial, não explorado por ninguém. E ele queria que a empresa quisesse pagar ao profissional desse nicho, sem precisar enganar ninguém ou inflacionar nada. Para que fosse algo objetivo: a pessoa nessa posição deveria receber muito dinheiro. Um verdadeiro maluco, em suma.
A busca não demorou muito. Na empresa onde esse rapaz trabalhava, havia um nicho completamente livre, que poderíamos chamar de "organização dos processos de negócios". Em toda empresa existem um monte de problemas. Sempre tem algo que não funciona, e não há ninguém para corrigir o processo de negócios. Então, ele decidiu tentar ser o especialista que poderia ajudar o proprietário a resolver seus problemas nos processos de negócios.
Naquele momento, 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 encontrar um trabalho semelhante em uma semana. Enfim, esse rapaz decidiu que não haveria problema se, de repente, não funcionasse e ele fosse demitido.
Ele tomou coragem e foi até o proprietário. Ofereceu-se para melhorar o processo mais problemático que existia no negócio. Naquele momento, era o controle de estoque. Agora, todos que trabalham nesta empresa até se envergonham de lembrar desses problemas, mas os inventários realizados trimestralmente mostravam discrepâncias entre o sistema de contabilidade e os saldos reais de dezenas de porcento. Tanto em valor quanto em quantidade, e no número de itens. Isso era um desastre. A empresa realmente tinha os saldos corretos no sistema de contabilidade apenas quatro vezes ao ano – no dia seguinte ao inventário. Esse foi o processo que nosso garoto começou a organizar.
O garoto combinou com o proprietário que deveria reduzir as discrepâncias dos resultados do inventário pela metade. Além disso, o proprietário não tinha muito a perder, porque antes do nosso herói, várias tentativas de corrigir tudo já haviam sido feitas por diferentes funcionários, e, em geral, a tarefa era considerada praticamente insolúvel. Tudo isso aumentava muito o interesse, porque se tudo desse certo, o cara automaticamente se tornaria alguém que sabe colocar ordem e resolver tarefas insolúveis.
Assim, ele tinha a tarefa de, ao longo de um ano, reduzir as discrepâncias nos resultados do inventário pela metade. No momento em que o projeto começou, ele não tinha ideia de como conseguir isso, mas entendia que o controle de estoque é algo simples, então ainda conseguiria fazer algo útil. Além disso, reduzir as discrepâncias de dezenas de porcento para um dígito – isso, pelo visto, não é tão difícil. Todos que trabalharam na área de consultoria ou em atividades semelhantes entendem que a maioria dos problemas de processo é resolvida com ações bastante simples.
De janeiro a maio, ele se preparou, automatizou algumas coisas, reescreveu o processo de controle de estoque, mudou os fluxos de trabalho dos armazeneiros, contadores e reformulou 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, uma nova vida começou – o trabalho de acordo com suas regras. Para acompanhar os resultados, a empresa começou a realizar inventários com mais frequência – a cada dois meses. Os primeiros resultados já eram positivos, e até o final do ano, as divergências nos resultados da auditoria caíram para frações de um por cento.
O sucesso foi colossal, mas sua sustentabilidade não era acreditada. O rapaz duvidava que o resultado se manteria se ele se afastasse e parasse de observar o processo. No entanto, o resultado existia, e ele obteve tudo o que havia acordado com o proprietário. Depois, ao longo de alguns anos, a sustentabilidade do resultado foi confirmada — por vários anos, as divergências permaneceram dentro de 1%.
Então ele decidiu repetir o experimento e sugeriu ao proprietário melhorar outro processo problemático – o suprimento. Havia escassez que impedia o envio dos volumes que nossos clientes desejavam. Foi acordado que, em um ano, as escassezes seriam reduzidas pela metade, e o rapaz ainda realizaria de 10 a 15 projetos relacionados ao 1C — para automatizar diferentes processos de negócios e outras atividades.
No segundo ano, novamente tudo foi concluído com sucesso, as escassezes caíram em mais de 2 vezes, todos os projetos de TI foram finalizados com êxito.
Como o salário já atendia totalmente todas as exigências daquele rapaz, por cerca de dois anos, ele decidiu se estabelecer um pouco, se acalmar e ficar em um lugar aconchegante e quente que ele mesmo havia criado.
O que isso representava? Formalmente, ele era o diretor de TI. Mas quem ele realmente era, é difícil de entender. Afinal, o que faz um diretor de TI? Geralmente, ele administra a infraestrutura de TI, lidera os administradores de sistema, implementa o sistema ERP e participa de reuniões no conselho de diretores.
Uma das principais responsabilidades desse cara era participar dos processos de mudança, principalmente na geração e na iniciação desses processos, na busca e na proposição de soluções, na aplicação de novas metodologias de gerenciamento, na avaliação das mudanças propostas, na análise da eficácia de outras funções e departamentos e, finalmente, na participação direta no desenvolvimento estratégico da empresa, até na elaboração independente do plano estratégico de toda a companhia.
Ele recebeu carta branca. Podia participar de qualquer reunião para a qual anteriormente não tinha acesso. Sentava-se lá com um caderno, anotava alguma coisa ou apenas ouvia. Falava pouco. Depois começou a brincar no telefone — afirmava que assim a memória associativa trabalhava melhor.
Em reuniões, raramente produzia algo útil. Saía, pensava um pouco, e depois vinha um e-mail — ou com críticas, ou com opiniões, ou com sugestões, ou com descrições de soluções que já havia aplicado.
Mas, na maioria das vezes, ele mesmo organizava as reuniões. Encontrava um problema, pensava em soluções, identificava os interessados e arrastava todos para a sala de negociações. E lá, fazia como conseguia. Convencia, motivava, argumentava, discutia, conseguia resultados.
Oficialmente, ele era considerado a terceira pessoa da empresa, depois do proprietário e do diretor. Naturalmente, ele irritava bastante todos os ‘executivos da empresa’, começando pelo número 4. Especialmente com suas calças rasgadas e camisetas vibrantes, além do tempo do proprietário.
O proprietário dedicava a ele uma hora por dia. Todos os dias. Eles conversavam, discutiam problemas, soluções, novos negócios, direções de desenvolvimento, indicadores e eficácia, desenvolvimento pessoal, livros, e simplesmente — a vida.
Mas esse garoto era estranho. Aparentemente — deveria estar satisfeito, a vida ia bem. Mas não. Ele decidiu refletir.
Ele ficou curioso: por que ele conseguiu, enquanto outros não? O proprietário também o incentivava: dizia que queria que os outros também conseguissem organizar as coisas, pois havia muitos gerentes, que geralmente se ocupam da gestão operacional e do planejamento estratégico, mas praticamente ninguém se ocupa de mudanças sistemáticas em seus processos. Pode estar registrado na descrição de funções que eles devem acelerar seus processos e aumentar sua eficiência, mas na prática ninguém faz isso. Por que isso acontece? O rapaz também ficou curioso sobre isso e começou a conversar com todos esses gerentes.
Ele foi até o vice-diretor de qualidade e sugeriu implementar gráficos de controle de Shewhart, para que a produção fosse melhor do que a japonesa. Mas acabou descobrindo que o colega não sabia o que eram gráficos de controle de Shewhart, o que é controle estatístico de processos, e apenas tinha ouvido falar do ciclo de Deming na gestão da qualidade. Tudo bem…
Ele foi até outro vice-diretor e sugeriu implementar controle gerencial. Mas aqui também não encontrou apoio. Um pouco depois, ele descobriu sobre boundary management e propôs a todos os vice-diretores implementar a parte sistêmica dessa metodologia para melhorar os processos. Mas, não importa quanto ele conversasse, ninguém parecia interessado em entender o que estava sendo discutido. Talvez fosse desinteressante ou muito complexo. Mas, na prática, ninguém realmente se aprofundou.
Em resumo, ele contou tudo o que sabia e aplicava na empresa. Mas ninguém realmente o entendeu. Até hoje não compreendem porque, por exemplo, tudo foi corrigido na contabilidade de estoque, e como isso se relaciona com controle gerencial e gerenciamento de limites.
Por último, ele se dirigiu aos seus programadores - na equipe havia 3 pessoas. Ele falou sobre gerenciamento de limites, controle gerencial, gerenciamento de qualidade, agile e scrum... E, para sua surpresa, todos entenderam e até puderam discutir com ele, incluindo as sutilezas técnicas e metodológicas. Eles entenderam porque os projetos de estoque e suprimentos tiveram sucesso. E foi então que o rapaz teve uma epifania: na verdade, o mundo será salvo pelos programadores.
Programadores, ele percebeu – são os únicos que podem realmente entender os processos de negócios com a detalhamento necessário.
Por que exatamente eles? Na verdade, ele nunca encontrou uma resposta definitiva. Apenas formulou algumas sugestões em forma de tese.
Em primeiro lugar, os programadores conhecem as áreas de negócios, e na verdade, conhecem-nas melhor do que qualquer outra pessoa na empresa.
Além disso, os programadores realmente entendem o que é um algoritmo de processo. Isso é importante porque os processos de negócios são algoritmos, e os elementos neles podem estar banalmente desalinhados. Por exemplo, no processo de suprimento em que o rapaz estava trabalhando, o primeiro passo é elaborar o plano anual de compras e o segundo é a compra diária. Esses passos estão ligados por uma conexão direta, ou seja, presume-se que, de acordo com esse algoritmo, as pessoas devem trabalhar – elaborar o plano anual de compras e imediatamente executar o pedido. O plano anual de compras é elaborado uma vez por ano, enquanto o pedido chega 50 vezes por dia. Com isso, o algoritmo se encerra e deve ser seguido. Na verdade, ele raciocinou, para os programadores, o conhecimento de algoritmos é uma vantagem competitiva, porque qualquer outra pessoa que não esteja familiarizada com eles não entende como o processo de negócios deve funcionar e como isso pode ser representado.
Outra vantagem dos programadores, segundo o rapaz, é que eles têm tempo livre suficiente. Todos nós entendemos como um programador pode gastar três vezes mais tempo em uma tarefa do que realmente leva, e poucas pessoas percebem isso. Isso é, novamente, uma vantagem competitiva, porque para organizar um processo de negócios, é preciso ter bastante tempo livre — pensar, observar, estudar e experimentar.
A maioria dos gerentes, segundo o rapaz, não tem esse tempo livre e se orgulham disso. Embora, de fato, isso signifique que a pessoa não pode se tornar eficiente, porque não tem tempo para aumentar a eficiência — um ciclo vicioso. Em nossa cultura, estar ocupado é um traço desejável, então tudo continua estagnado. E para nós, programadores, isso é uma vantagem. Podemos encontrar tempo livre e refletir sobre tudo.
Os programadores, ele contou, podem rapidamente mudar o sistema de informação. Isso não se aplica a todas as empresas, mas onde quer que ele trabalhou, era possível fazer quaisquer ajustes que desejassem. Especialmente, se não interferissem no trabalho de ninguém. Por exemplo, ele poderia implementar um sistema que secretamente mediria as ações dos usuários e usaria essas informações - para analisar a eficiência do mesmo departamento contábil e monitorar o custo da contabilidade.
E a última coisa que me lembrei de suas palavras é que os programadores têm acesso a uma grande quantidade de informações, pois possuem acesso administrativo ao sistema. Portanto, podem usar essas informações em sua análise. Ninguém mais em uma fábrica comum tem esse recurso.
E então ele saiu. Durante as duas semanas de aviso prévio, forçamos ele a compartilhar sua experiência, pois queríamos continuar o trabalho que ele estava realizando. E seu cargo estava se tornando vago.
Durante alguns dias, o colocamos em uma cadeira, ligamos a câmera e gravamos seus monólogos. Pedimos que falasse sobre todos os projetos realizados, métodos, abordagens, sucessos e falhas, causas e consequências, retratos de líderes, etc. Não impusemos muitas limitações, pois não sabíamos o que se passava na cabeça dele.
Nos monólogos, claro, havia principalmente bobagens e risadas - ele estava em um ótimo estado de espírito, pois estava saindo de um lugar afastado para São Petersburgo. E para onde ir trabalhar em São Petersburgo? Para a Gazprom, claro.
Mas conseguimos extrair algumas coisas úteis de seus monólogos. Vou contar o que me lembro.
Então, recomendações daquele rapaz. Para quem quiser tentar organizar os processos de negócios.
Para trabalhar com isso, em primeiro lugar, é preciso ter um certo nível de 'insensibilidade'. É necessário não ter medo de perder o emprego, não ter medo de arriscar, não ter medo de conflitos com colegas. Ele fazia isso facilmente, pois começou sua jornada quando tinha apenas seis meses na empresa e não teve tempo de se relacionar com ninguém, nem pretendia fazer isso. Ele entendia que as pessoas vêm e vão, e para ele, o que importava eram seus próprios resultados e sua avaliação pelo proprietário do negócio. Se os colegas o tratavam bem ou mal - isso pouco o preocupava na época.
O segundo ponto é que, para trabalhar efetivamente nisso, você terá que aprender, infelizmente. Mas não aprenda em um MBA, nem em cursos, nem em instituições, mas por conta própria. Por exemplo, no seu primeiro projeto, relacionado ao armazém, ele agiu instintivamente, não sabia nada, apenas o que era "gestão da qualidade".
Quando ele começou a ler literatura sobre os métodos de aumento de eficiência, descobriu as tecnologias que já aplicava. Ele as usou por instinto, e percebeu que isso não era uma invenção sua, tudo já tinha sido escrito há muito tempo. No entanto, ele gastou tempo, e muito mais do que se tivesse lido o livro certo logo de cara. É importante entender que quando se estuda uma metodologia específica, nenhuma delas, mesmo a mais avançada, resolverá todos os problemas do processo de negócios.
A segunda dica é que quanto mais metodologias você conhecer, melhor. Por exemplo, na antiga Japão, viveu Miyamoto Musashi – um dos mais famosos espadachins, autor do estilo de duas espadas. Ele estudou em uma escola com algum mestre e depois viajou pelo Japão, lutando com vários adversários. Se o adversário era mais forte, as viagens eram interrompidas por um tempo, e Musashi se tornava aprendiz. Como resultado, ele adquiria habilidades diversas de diferentes mestres em poucos anos e formou sua própria escola, acrescentando algo pessoal. No fim, ele alcançou uma maestria única. Aqui é a mesma coisa.
Claro, você pode agir como consultores de negócios. Eles são realmente ótimos profissionais. Mas, geralmente, eles vêm para implementar alguma metodologia, e aplicam uma que não é necessária para o negócio. Também tivemos essas situações tristes: ninguém sabe como resolver um problema e ninguém quer pensar em como resolvê-lo. Começamos a procurar na internet ou chamar um consultor, e perguntamos a ele o que pode nos ajudar. O consultor pensa e diz que precisamos implementar a teoria das restrições. Pagamos por essa recomendação, gastamos com a implementação, mas o resultado é zero.
Por que isso acontece? Porque o consultor disse que devemos implementar determinado sistema, e todos concordaram com ele. Ótimo, mas uma única metodologia não resolve todos os problemas de um único processo de negócios, especialmente se as premissas iniciais não coincidirem — as nossas e as que são necessárias para a implementação da metodologia.
Na prática que o rapaz recomenda, é preciso pegar o melhor e implementar o melhor. Não usar os métodos por completo, mas sim suas características-chave, funcionalidades, práticas. E o mais importante – é preciso entender a essência.
Vamos pegar, disse ele, por exemplo, o scrum ou o ágil. Em seus monólogos, o rapaz repetiu várias vezes que nem todos entendem completamente a essência do scrum. Ele também leu o livro de Jeff Sutherland, que para alguns parece uma leitura leve. Para ele, foi uma leitura profunda, porque uma das bases fundamentais do scrum é a gestão da qualidade, e isso é abordado diretamente no livro.
Está escrito sobre a produção da Toyota, sobre como Jeff Sutherland apresentou o scrum no Japão, quão bem ele se adaptou e o quanto estava próximo da filosofia deles. 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. Todo o resto que existe no scrum – entregas em etapas, satisfação do cliente, uma lista clara de tarefas para o período do sprint – também é importante, mas tudo isso deve avançar cada vez mais rápido. A velocidade de trabalho deve aumentar continuamente nas unidades em que é medida.
Talvez isso se deva à tradução, porque aqui o livro foi traduzido como 'Scrum – um método revolucionário de gestão de projetos', mas se traduzirmos o título em inglês literalmente, resulta em: 'Scrum – o dobro em metade do tempo', ou seja, até mesmo no nome há uma referência à velocidade, que é a função-chave do scrum.
Quando esse rapaz implementou o scrum, na primeira mês a velocidade dobrou sem mudanças significativas. Ele encontrou pontos para mudanças, modificou o próprio scrum para que funcionasse muito mais rápido. A única questão, como se escreve na internet, foi: 'Aumentamos a velocidade em dobro, agora precisamos entender o que fazemos com essa velocidade?'. No entanto, esse já é um assunto completamente diferente...
Ele também recomendou pessoalmente várias metodologias. Chamou-as de fundamentais e essenciais.
A primeira — gestão de limites.
É ensinado na «Skolkovo», e de acordo com o rapaz, não há outros livros ou materiais. Ele teve a sorte de participar de uma palestra de um professor de Harvard, que prega sobre gerenciamento de fronteiras, além de ter lido alguns artigos na Harvard Business Review sobre o trabalho de Eric Trist.
O gerenciamento de fronteiras fala sobre a necessidade de enxergar limites e trabalhar com eles. Existem limites em toda parte — entre departamentos, entre diferentes tipos de trabalho, entre funções, entre trabalho operacional e analítico. O conhecimento sobre gerenciamento de fronteiras não revela verdades superiores, mas permite ver a realidade de uma maneira diferente — através da lente das fronteiras. Assim, é possível gerenciá-las — estabelecendo limites onde necessário e removendo-os onde são uma barreira.
Mas o rapaz falava mais e com mais frequência sobre controladoria. Era uma obsessão para ele.
Controladoria, de forma resumida, é gerenciamento baseado em números. Aqui, ele dizia, cada parte da definição é importante — tanto 'gerenciamento', quanto 'baseado' e 'números'.
Nós, dizia ele, estamos mal em todos os três componentes da controladoria. Especialmente se considerarmos que eles estão intimamente interconectados entre si e com outras partes do sistema de negócios.
A primeira coisa que está ruim — os números. Eles são poucos e de baixa qualidade.
Uma parte significativa dos números que utilizávamos vinha do sistema de informações 1C. Porém, a qualidade dos dados no 1C, segundo ele, deixa a desejar. Pelo menos, devido à possibilidade de alterar dados retroativamente.
É evidente que a culpa não é dos desenvolvedores do 1C — eles apenas levam em conta as exigências do mercado e a mentalidade da contabilidade local. Mas, para fins de controladoria, os princípios de trabalho do 1C com dados precisam ser mudados na empresa específica.
Depois, os números do 1C, segundo suas palavras, passam por um processamento semi-manual, usando Excel, por exemplo. Esse processamento também não melhora a qualidade dos dados, nem a rapidez.
No final das contas, o relatório final ainda será revisado por alguém, para garantir que os números enviados ao chefe não contenham erros. No resultado, os números chegam ao destinatário bonitos, verificados, mas muito tarde. Normalmente — após o período (mês, semana, etc.).
E aqui, dizia ele, tudo é muito simples. Se os números de janeiro chegaram em fevereiro, você não pode mais gerenciar as atividades de janeiro. Porque janeiro já terminou.
E se os números forem baseados na contabilidade e a empresa for uma organização comum, com a entrega trimestral do IVA, então o líder obtém números relativamente adequados uma vez por trimestre.
A partir daqui, está claro. Você obtém os números uma vez por mês — você tem a oportunidade de gerenciar com base nos números (ou seja, executar o controle) 12 vezes por ano. Se você pratica relatórios trimestrais — gerencia 4 vezes por ano. Além disso, há um bônus — o relatório anual. Mais uma vez, você pode conduzir.
O resto do tempo, a gestão, como regra, é feita às cegas.
Quando (e se) os números finalmente aparecem, entra em cena o segundo problema — como gerenciar com base nos números? Com esse ponto de suas reflexões, eu realmente não consegui concordar.
O sujeito afirmava que se o líder nunca teve números antes, sua aparição causará um efeito uau. Ele começará a olhar e mexer nos números de todas as maneiras, convocará pessoas para explicações e investigações. Depois de brincar com os números e realizar análises, ameaçando a todos os funcionários com o aviso de que "agora não vou deixar vocês em paz", o líder rapidamente se acalma e abandona o assunto. Ele deixará de usar a ferramenta. E os problemas permanecerão.
Isso acontece, ele dizia, devido à falta de competências do líder. No controle, em primeiro lugar. O líder simplesmente não sabe o que fazer com esses números. O que comfazer — ele sabe, mas como agir — não. Fazer — é o que foi mencionado acima (reclamar, brincar). Agir — é um processo de negócio diário.
Ele afirmava que era muito simples: o número deve se tornar parte do processo de negócio. No processo de negócio, deve estar claro: quem, o que, e quando deve agir ao desvio do número da norma (quaisquer opções — acima do limite, abaixo do limite, saída do corredor, tendência presente, não cumprimento do quantil, etc.)
E aqui ele destacou o dilema chave: o número existe, ele deve se tornar parte do sistema de negócio para aumentar a eficiência da gestão, mas... isso não acontece. Por quê?
Porque o líder russo não entregará um pedaço de seu poder ao concorrente.
Os concorrentes do líder russo — um processo de negócio de qualidade e funcionando, uma motivação mútua bem pensada e uma automação correta — infelizmente, deixarão o líder sem trabalho.
É uma loucura, concordam? Especialmente sobre os líderes. Bem, eu falei, agora decidam por si mesmos.
Um pouco menos, mas ainda assim muito, na minha opinião, ele falava sobre Scrum.
Com certeza, ele disse para ler e tentar o Scrum na prática. Se, segundo ele, você leu, mas não tentou — considere que você não sabe. É melhor ler um livro, como o de Sutherland, em vez de artigos e guias estranhos na internet.
Scrum, ele disse, só é compreendido pela prática e com medições obrigatórias dos volumes de trabalho realizados. Experimente pessoalmente os dois papéis mais importantes — o dono do produto e o Scrum Master.
É especialmente importante, segundo o cara, vivenciar na prática o papel do Scrum Master, quando você consegue aumentar o volume de tarefas concluídas por sprint, sem aumentar recursos e custos da sprint.
E ele também incluiu a TOC (Teoria das Restrições) em seu top.
Esses, segundo o cara, são os princípios básicos e fundamentais para aumentar a eficácia que podem ser aplicados em praticamente qualquer área, em qualquer processo de negócio e sistema de negócios em geral.
Quando ele descobriu que não estávamos familiarizados com a TOC, ele parou de falar. Apenas acrescentou que não nos privaria do prazer de ler os livros de Eliyahu Goldratt. A recomendação foi semelhante à do Scrum — leia e experimente. Tipo, independentemente da posição que você ocupa ou do trabalho que realiza, há espaço para aumentar a eficácia com os métodos da TOC.
Depois, aparentemente, ele esgotou sua bagagem de métodos e disse: misture princípios para criar soluções aplicáveis em situações específicas.
Isso, ele diz, é a principal recomendação, a chave para o sucesso. Compreenda os princípios, a essência, e crie soluções aplicáveis únicas — processos e sistemas de negócios.
Depois ele se esforçou para lembrar alguma citação, e no final precisou recorrer à internet. Descobriu que a citação era de um artigo chamado "De pé sobre os ombros de gigantes" de Eliyahu Goldratt:
«Há uma diferença entre soluções aplicadas (aplicações) e conceitos fundamentais que sustentam essas soluções. Os conceitos são genéricos, enquanto as soluções aplicadas são a adaptação de conceitos a um ambiente específico. Como já vimos, essa adaptação não é simples e exige o desenvolvimento de determinados elementos da solução. Devemos lembrar que uma solução aplicada é baseada em pressupostos iniciais (às vezes, ocultos) sobre o ambiente específico. Não devemos esperar que essa solução aplicada funcione em um ambiente para o qual os pressupostos iniciais não são válidos.»
Disse que o trabalho do programador e do "melhorador de processos de negócios" é muito semelhante. E foi embora.
Fonte: habr.com
