Quando um processo deve ser arte, e não ciência ?

Na Harvard Business Review deste mês foi publicada uma matéria de dois professores do Dartmouth College mostrando que às vezes o movimento de padronização de processos vai longe demais. Segundo os autores, certos processos exigem o critério de um artista, e assim devem ser administrados. Gostaria de relacionar esta visão com os processos de tecnologia da informação, relatando alguns exemplos úteis para os leitores do blog.

Um processo de vendas que deu certo para infraestrutura de redes pode ser adotado para todos os serviços de TI ? ou o melhor seria que cada área tivesse seu processo específico alinhado com um processo corporativo ? faz sentido, para um provedor de TI, desenvolver e documentar um processo detalhado que siga os últimos padrões ISO ? Ou será que dar mais treinamentos e autonomia ao pessoal é o que garantiria uma qualidade superior? é possível ter mais qualidade administrando desenvolvedores de softwares como se fossem mecânicos ? É possível que um erro vire uma oportunidade de aprendizado ?

Há processos que naturalmente resistem à definição e à padronização – ou seja, que são mais arte do que ciência. Geralmente quando as suas entradas são variáveis e o cliente preza a variação nos resultados. Com alguns exemplos ficará fácil entender. A padronização de processos é ensinada em cursos de administração, é parte de programas Seis Sigma e ISO, é automatizada através de ferramentas BPM como os da BEA, Tibco e Aris e utiliza alguns modelos como SIPOC, UML, IDEF0 ou BPMn. Utilizei algumas ferramentas de BPM em clientes para produzir algumas dezenas de fluxos de processos automatizados para redução de papel, padronização, agilidade e “amarração” de atividades visando um objetivo final para o negócio, não separando processos padronizáveis ou não. Lembro também que melhores práticas de padronização são defendidas por gurus da área como Michael Hammer em seu livro “A Agenda” e Thomas Davenport no seu famoso artigo de 2005 na HBR sobre “Comoditização de Processos”, cuja representação máxima está no projeto “Process Handbook” do MIT (http://ccs.mit.edu/ph/). O PH é uma biblioteca de processos já implantados com sucesso em grandes empresas e tem utilização livre. Outro bom exemplo de padronização está na Toyota, conforme relatado em publicações como “The Toyota Way” que defende o conceito de trabalho padronizado dentro do STP (Sistema Toyota de Produção), combinada com outras práticas como Just-in-time e controles visuais para detectar desvios.

Bem, esta é a minha visão. No entanto, o problema identificado pela reportagem da HBR é que a padronização de processos pode, ironicamente, minar o próprio desempenho que pretende otimizar. Muitos processos funcionam melhor quando, em vez de rigidamente controlados, são tratados como um trabalho artístico. O Gerente deve separar todo processo artístico de processos de apoio que possam ser padronizados. Um grande vendedor de serviços de TI, por exemplo, busca em processos de vendas e sistemas de relacionamento com o cliente informações básicas e coerentes (padronizável) para ajustar seu discurso de vendas a cada cliente (não padronizável).

“A padronização exime o profissional da responsabilidade e faz com que ligue o piloto automático em vez de analisar melhor os detalhes do processo.”

"Um processo artístico precisa de indicadores externos de sucesso, como o feedback de clientes. Processos padronizados são medidos e avaliados à luz de normas e parâmetros determinados e acordados (SLA ? ), ao passo que processos artísticos são avaliados por meio da interação com o cliente."

A padronização e o controle são importantes, porém a arte utilizada em processos como vendas, inovação, gestão do conhecimento, atendimento ao cliente, desenvolvimento de software e até mesmo auditoria (porque não? ) permite uma flexibilidade, uma criatividade e um dinamismo impossíveis de serem reproduzidos por uma abordagem puramente científica. Os autores defendem que o desenvolvimento de uma nova aplicação em geral exige a iteração constante com cliente e decisões de simplificar o trabalho (imagine agora com os métodos ágeis). O atendimento ao cliente em um service desk deve ter flexibilidade de abandonar o roteiro e fazer o que achar melhor para o momento (lembrem-se o que a reportagem cita: existem variações e situações diferentes nas solicitações dos clientes e que exigem flexibilidade). Quanto a este ponto, lembro de um trecho do livro “O Futuro da Competição” de C.K. Phahalad, famoso guru de estratégia”, que manifesta sua irritação pelo fato dos atendentes de service desk serem geralmente avaliados em termos de produtividade e metas estipuladas em processos, em vez do valor e do retorno do atendimento para o cliente.

Bem, os autores concluem que tanto arte como ciência têm um papel importante nos processos da empresa. Não se pode pensar apenas em ganhos de produtividade e metas sem pensar nas pessoas, inovação e relacionamento com o cliente, e vice-versa. Lembro-me das lições do STP (Sistema Toytota de Produção) sobre melhoria contínua. Quando um problema surge, qualquer profissional da equipe é responsável e dispõe de autonomia para achar uma solução. Na Toyota, espera-se que cada um aja de acordo com o acha certo. Autoridade e responsabilidade cabem ao indivíduo, e não a um cargo ou tempo de serviço. Coloca-se a responsabilidade pela qualidade nas mãos dos membros da equipe. Eles sentem a responsabilidade, eles sentem o poder. Eles sabem que são levados em consideração. Eis um bom exemplo de arte que pode ser adaptado aos processos de TI.