Conhecimento organizacional a chave para a melhoria continua

Paulo de Carvalho 1,2, Rodrigo Magalhães 3, José Tribolet4.

1) Centro de Engenharia Organizacional, INESC Inovação, Lisboa, Portugal

2) Vodafone Portugal, Lisboa, Portugal

paulo-v.carvalho@vodafone.com

3) Departamento Engenharia Informática, Instituto Superior Técnico, Universidade Técnica de Lisboa, Centro de Engenharia Organizacional, INESC Inovação, Lisboa, Portugal

rmagalhaes@ceo.inesc.pt

4) Departamento Engenharia Informática, Instituto Superior Técnico , Universidade Técnica de Lisboa, Centro de Engenharia Organizacional, INESC Inovação, Lisboa, Portugal

Jose.Tribolet@inesc.pt

Resumo

Vivemos a revolução da informação, os sistemas de informação transformam a sociedade e as organizações. A informação evidencia o saber e o património intelectual ganha uma importância incontornável. Torna-se o bem mais preciso para a maioria das organizações. Estes dois fenómenos incutem uma mudança profunda na natureza produtiva das organizações. A informação e o conhecimento são transaccionados como um bem material. O conhecimento como património tem que ser gerido.

Mas o que é o conhecimento? Como se gere? As organizações estão desenhadas e preparadas para esse desafio?

Este artigo pretende, a partir dum resumo de um caso de aplicação real, explorar e propor linhas de investigação que contribuam para a resposta a estas questões. A exploração de uma “experiência natural1” permitirá identificar as ligações entre informação, conhecimento e desenho organizacional.

Palavras chave: Organização, Desenho Organizacional, Tratamento de Excepções, Melhoria Continua, Conhecimento Organizacional, Gestão de Conhecimento, Cooperação

1. Introdução

O Novo conhecimento começa sempre a partir do individuo, [Nonaka 1991]. “A Gestão do conhecimento” tem sido um tema atractivo para as organizações. A Informação, e o conhecimento como chave para a diferenciação e competitividade [Porter 1985], reúnem um consenso alargado. Diversas organizações iniciam projectos técnicos com o objectivo explicito de

1 Experiência Natural – Experiência cientifica onde os participantes alteram o seu comportamento no decurso da mesma num processo de co-evolução e aprendizagem.

capturarem o conhecimento, sem no entanto entenderem a sua verdadeira natureza, [Nonaka 1991].

Frequentemente as soluções técnicas colocam o seu enfoque na informação, no seu ciclo de vida, disseminação e gestão. Mas a informação, por si só, não assegura a captura ou propagação de conhecimento.

Outra abordagem consiste em gerir as competências individuais. Assegurar que os indivíduos têm as competências que lhes permitam desempenhar os seus papéis de forma adequada. Gerem-se os recursos em “pool”, permitindo a sua optimização, disponibilizando as “pools” de recursos de forma inteligente e ágil, [Lindgren et al. 2004]. Mas, sem outra intervenção, o conhecimento adquirido irá permanecer no nível individual.

“Conhecimento Organizacional” e “Aprendizagem Organizacional” são dois momentos da mesma acção – a aprendizagem. O indivíduo “sabe” porque aprendeu no passado. Este facto parece tão óbvio, mas é revelador, centra a atenção no acto de aprender. Aprender é um processo ligado à acção, assim sendo, a gestão do conhecimento não pode ser estática.

2. Experiencia Natural

A aprendizagem organizacional é um processo de detecção e correcção de erros”, [Argyris 1977].

A experiência que se retrata neste ponto, designa-se por experiência natural uma vez que participantes e investigador alteram o seu comportamento e análise no decurso da mesma, num processo de co-evolução, aprendizagem e transferência de conhecimento.

As imprecisões e dificuldades resultantes ajudaram à reflexão, aproximando os métodos científicos desenvolvidos pelos teóricos da sua aplicação.

Após a apresentação do problema e da sua envolvente, descrevem-se cada um dos passos do projecto. Exploram-se as metodologias subjacentes aos vários passos do projecto em dois vectores: primeiro aproveitando o caso prático para posteriormente solidificar a aproximação alicerçando-a no conhecimento e investigações recentes lançando pistas para futuros desenvolvimentos.

3. O Problema e suas Envolventes

O Departamento de Operações e Suporte da Vodafone está estruturado numa aproximação típica do mundo das telecomunicações2. Uma unidade de “primeira linha” (1ª linha), responsável por funções de supervisão 24hx7d. A 1ª linha garante interface com as unidades de apoio ao cliente. Assegurando funções idênticas às de um “service desk” ITIL3. Esta unidade garante interface com especialistas nas diversas tecnologias que monitoriza. Estas unidades de especialistas, designadas genericamente por “segunda linha”(2ª Linha), garantem capacidade e conhecimento para despiste de problemas complexos.

A 1ª linha assegura a sua função de monitorização recorrendo a um interface onde são mostrados alarmes correspondendo a eventos anómalos (HP-OVO4). Estes eventos provêm das plataformas, sistemas e serviços e retratam excepções ao seu funcionamento. Cada alarme estimula uma acção

2 Consultar http://www.tmforum.org/ para mais detalhes 3 ITIL - ITIL – IT Information Library consultar http://www.itil-officialsite.com/ para mais informação 4 HP-OVO: HP OpenView Operations

por parte da 1ª linha, num processo designado por “Action on Alarm” (AoA). Os alarmes têm um formato comum5, contendo, entre outras indicações, informação descritiva da situação que retratam, a sua severidade e a sua origem.

Pretende-se que o processo de AoA transfira para a primeira linha capacidade e autonomia para actuar na causa da excepção. Caso não exista, a excepção deve ser escalada para a 2ª linha apropriada.

Igualmente, os incidentes reportados por clientes, via unidades de suporte ao cliente, são maioritariamente resolvidos pela 1ª linha. Caso não exista capacidade de resolução, essas reclamações são escaladas para a 2ª linha. Este processo tem a designação de “action on customer complaints” (representado pelo acrónimo AoOS, OS corresponde a ordem de serviço).

Estes dois processos compõem um processo principal designado por “Incident&Problem”.

Existiam diversos problemas relacionados com estes processos:

• Não existia uma consciência partilhada dos incidentes activos nem dos problemas em investigação.

• Os mecanismos para passagem de informação referente aos processos de AoA e AoOS eram baseados em eMail, e pouco formais. Frequentemente os indivíduos das unidades de 1ª e 2ª linha trocavam eMails revelando desencontros quanto as acções a executar na sequencia de um determinado alarme ou reclamação de clientes.

• Estes desencontros davam origem a escalonamentos frequentes. Cada escalonamento estava associado a uma enorme frustração por parte da 1ª linha, impotente para actuar, igualmente por parte das 2ª linhas, inconformadas pela incapacidade para 1ª linha.

• O esforço das 2ªs linhas divergia do domínio do problema (onde o seu conhecimento se traduziria num maior valor) para o domínio do incidente.

4. Aplicando uma visão sistémica ao problema

Os modelos mentais, tal como propõe [Senge 1990], numa das cinco disciplinas da “organização que aprende”, são chave no processo de aprendizagem individual. O processo de aprendizagem colectiva resulta da dialéctica que, partindo dos modelos mentais individuais expostos, constrói uma visão partilhada que modifica e faz evoluir o modelo mental individual [Parboteeah, P. et al. 2007].

A construção desta visão partilhada, segundo [Senge 1990], tem como base o entendimento sistémico dos fenómenos com que lida a organização.

A Figura 1 retrata a versão final do modelo partilhado de suporte. Este modelo resultou da discussão dos vários elementos pertencentes as unidades de primeira e segunda linha. Depois de estabilizado, o modelo criou um alinhamento natural entre as unidades.

5 Para mais informação consultar www.ietf.org/rfc/rfc1157.txt

Figura 1 – Modelo Partilhado; Visão sistema do processo de suporte inspirado em [Mourão 2007] , [Argyris 1977]

A 1ª linha, responsável por observar o “processo em operação”, monitoriza o cumprimento de normas pré estabelecidas. Assim que surge uma excepção (um alarme ou reclamação) tenta activar mecanismos para a sua recuperação.

Pontualmente, a 1ª linha, dados os seus menores conhecimentos do domínio específico da excepção, tem uma capacidade reduzida para activar a sua recuperação. Apenas estará ao seu alcance a recuperação de excepções ditas “esperadas”. Neste contexto, entendem-se como excepções esperadas as excepções para as quais a unidade de primeira linha tem memória passada da sua ocorrência tendo adicionalmente assimilado, a partir dessas experiências passadas, quais os “mecanismos ” que conduzem à sua eliminação.

Caso a excepção seja classificada como não esperada, é escalada para a 2ª linha. A 2ª linha tem com responsabilidade a recuperação da excepção e o restabelecer da normalidade do processo. É ainda responsável pela criação dos mecanismos necessários para que a excepção não tenha novas ocorrências, ou para que em caso de nova ocorrência, existam mecanismos de detecção e recuperação que a permitam tratar como excepção esperada.

Os “loops de feedback” não fazem parte do tradicional desenho de processos. Se reflectirmos sobre a Figura 1 conseguimos perceber a importância das acções que transformam as excepções não esperadas em esperadas bem como as que eliminam as excepções esperadas ou ajustam as normas contribuindo para a eliminação das excepções. Da mesma forma, não se especificam quaisquer actividades que conduzam à partilha da memória sobre o tratamento de excepções, ou das acções executadas para a sua resolução.

Frequentemente a 2ª linha partilhava por email algumas das acções elaboradas para correcção de algumas excepções. Não fazendo parte integrante da acção essa informação não estava disponível como “memória” útil em novas ocorrências da mesma excepção, resultando num escalamento desnecessário.

A ausência destes “loops de feedback”, indispensáveis à partilha entre as unidades participantes neste processo traduz o problema de forma sistémica.

5. O Projecto “Wiki Operações” como visão partilhada

“Learning organizations are “organizations where people continually expand their capacity to create the results they truly desire, (…) where people are continually learning how to learn together”, [Senge 1990]

A visão sistémica do problema criou a predisposição para um projecto transversal que permitisse sustentar a troca de informação entre as várias áreas de suporte.

A necessidade de repositórios de informação, presente em diversas unidades, tinha resultado na emergência de wikis6 em adição as diversas ferramentas corporativas existentes. No entanto, emergindo a partir da necessidade de unidades particulares, estes wikis fechavam-se em torno dessas unidades, não permitindo uma verdadeira partilha.

O projecto, designado como Portal Operações, teria a ambição de garantir a partilha de informação, criando uma comunidade transversal à organização de suporte. Permitiria a migração dos wikis existentes, assegurando a autonomia de cada uma das unidades.

6. Escolha da Solução Técnica

A primeira reunião para apresentação do projecto e seus objectivos criou abertura para a iniciativa, no entanto existiu alguma resistência por parte de uma unidade que tinha investido na sua própria solução. Esta unidade estava disponível para partilharem o seu portal mas mostrava-se cépticas quanto à opção de um portal único.

A escolha da solução técnica serviria de alavanca para o restante projecto. Como ponto de partida, os requisitos iniciais resultaram da análise dos diversos wikis existentes e das funcionalidades que cada uma das unidades considerava indispensáveis. Em adição, acrescentaram-se requisitos que garantiam a autonomia de cada unidade bem como a integridade e segurança da informação disponibilizada.

Procuraram-se várias soluções freeware para gestão e administração de conteúdos. Cada uma das soluções foi avaliada usando uma grelha de 6 blocos de avaliação com 6 items cada.

7. A apresentação da solução técnica e constituição do grupo de partilha

A apresentação técnica permitiu criar um momento de socialização e discussão profunda sobre os objectivos do projecto.

Os presentes, representavam cada uma das unidades da direcção, concordaram quanto ao objectivo mas nem todos mostraram disponibilidade para abdicar das suas iniciativas a favor do projecto.

Argyris e Schon [Argyris 1977] ao estudarem os factores limitadores da aprendizagem depararam-se com um problema a que chamaram “Behavior-model”, explicava porque é que o comportamento nem sempre acompanhava a racionalidade exposta. Neste caso, justificava o facto de não obstante todos concordarem com a solução, nem todos estarem disponíveis para participar.

6 Wiki - Os termos wiki (pronunciado /uíqui/ ou /víqui/) e WikiWiki são utilizados para identificar um tipo específico de coleção de documentos em hipertexto ou o software colaborativo usado para criá-lo

O Projecto nascia assim limitado na sua participação, apenas 4 das 6 unidades convidadas a participar aceitaram os pressupostos do projecto. O projecto assentava em 6 pressupostos (requisitos) com o objectivo de incentivar a participação e colaboração dos vários grupos na sua construção comum:

1º Carácter publico da Informação: Por defeito, a informação publicada estaria disponível para todos os utilizadores autenticados. Apenas por razões de segurança estrita a informação deveria ser privada.

2º Independência: Cada indivíduo deve ter autonomia para publicar informação ou comentar a informação publicada.

3º Uniformização de Informação: A informação deveria ser estruturada para que cada “artigo7” representasse um tipo de informação assegurando a uniformização da estrutura e garantindo a expectativa do consumidor da informação.

4º Garantia de qualidade: A qualidade da informação disponibilizada deveria ser construída pelo conjunto utilizadores e reforçada pelos representantes de cada unidade. Os representantes, escolhidos de forma independente, tinham como propósito a coordenação e evolução do projecto, estabelecendo normas de publicação que facilitem a consulta e garantam a qualidade da informação publicada. Como sugestão, foi usado um modelo de controlo de qualidade idêntico ao da Wikipédia8 . Permite-se também que cada consumidor comente e avalie qualquer item de informação, garantindo o feedback da comunidade.

5º Os Tipos de Informação: A eficiência e eficácia dos mecanismos de procura foi um dos requisitos que os utilizadores classificaram como mais importante. Categorizar a informação parceria ser a forma mais apropriada de garantir este requisito.

6ª Partilha e Reutilização: Os itens de informação deveriam ser suficientemente atómicos para se evitar a sua repetição em diversos “artigos”. Preferencialmente itens transversais a vários grupos deveriam ser publicados uma única vez, servindo de “referencial” para todos os consumidores. Cada “artigo” deveria ser enriquecido com referências (automáticas de preferência) para conteúdos publicados.

A emergência destes pressupostos é interessantíssima. Reflectem alguns dos princípios fundamentais da participação de indivíduos numa actividade comunitária (tal como estudado por [Saveri, A et. al. 2005],[Parboteeah et. al. 2007]) passam por garantir independência e equidade de cada participante (ponto 2).

A Wikipedia funcionou como metáfora, acompanhando todo o projecto estabelecendo termos de comparação importantes.

Os pontos 5 e 6, presentes no propósito dos wiki-semantics, têm por base ontologias, neste caso no seu formato mais simples – Ontologia Simples tal como descrita por [McGuinness 2000].

8. A emergência de uma ontologia

Os pontos 5 e 6 foram considerados como elementos chave do sucesso ou insucesso do projecto. Os utilizadores com experiência acumulada através da elaboração de outros wikis reconheciam a

7 “Artigo” - Na solução Wiki escolhida cada artigo corresponde a uma “página” de conteúdo, um nó no portal. 8 Para mais informação consultar http://en.wikipedia.org/wiki/Wikipedia:About

importância da estruturação da informação. Nos wikis em que participavam tornava-se difícil encontrar a informação pretendida.

Os objectivos assemelhavam-se aos expostos por [McGuinness 2000] ao descrever o propósito das ontologias simples. Garantir um vocabulário controlado, permitir a organização da informação a disponibilizar, garantir expectativas realísticas na informação disponibilizada, garantir eficácia da procura, garantir o desambiguar de conceitos, facilitar o “browsing” de conteúdos.

Numa 1ª fase estabeleceu-se a ambição do projecto em torno do domínio de suporte. O Portal deveria ser capaz de responder ao tipo de questões que surgem associada ao processo de “Incident/Problem”. As respostas deveriam fazer sentido tanto nos contextos inter-unidade (o que cada individuo necessita para fazer suporte no contexto do seu grupo) mas também entre unidades (quais são os itens de informação transversais às unidades; mais especificamente quais são os necessários à relação primeira segunda linha).

Cada um dos participantes identificou um lote de questões que gostava de ver respondidas (resumem-se algumas destas questões):

• Qual o procedimento de resolução a aplicar a um determinado alarme?

• Qual o procedimento de despiste/ resolução a aplicar a uma cliente reclamação?

• Como classificar o impacto de um alarme ao nível do serviço?

• Como localizar a falha exposta por um alarme numa plataforma?

• Quais são os elementos que compõem um serviço?

• Quais são os procedimentos associadas a cada serviço?

O diálogo em torno destas questões e a procura da forma como as resolver fez emergir o sistema de classificação actualmente utilizado pelo projecto. A procura de termos que caracterizassem cada um dos itens de informação surgiu naturalmente.

Alguns dos termos propostos pelos participantes reuniam consenso, termos com serviço ou diagrama, no entanto nem sempre existia uma definição que capturasse o que se entendia pelo termo. Por exemplo, o termo serviço levou a múltiplas definições confundindo-se com outros termos de granularidade diferentes tais como “serviços web” ou “serviço de rede”. Foi necessário encontrar uma definição abrangente e que reunisse consenso.

Existiam termos com diversos sinónimos, alguns dos quais apenas aparentes, procurando-se o sinónimo cuja definição melhor traduzisse o que se pretendia com o termo. Foram eliminados todos os termos para os quais não se consegui encontrar uma definição adequada (tais como máquina). Abandonaram-se os termos para os quais não existia consenso. Utilizaram-se bases de conhecimento formais e informais tais como o SID9 o ITIL ou a Wikipedia

Neste processo, era frequente revisitar algumas das questões expostas, clarificando ou reforçando a questão, o que permitia descobrir termos ou relevar a sua importância.

A equipa concordou que a exploração de termos terminasse apesar do sentimento de falta de completude.

Os passos descritos são semelhantes aos primeiros passos propostos para a construção de ontologias [Uschold et. al. 1996][ Fernández et. al. 1999]. A necessidade de uma ontologia não requeria maior formalização que a encontrada.

9 SID – Shared Information Data modeler TMForum

Figura 2 – Processo adaptado para a construção da ontologia simples

9. A prova de conceitos

Não obstante terem emergido de um diálogo aberto e construtivo, os conceitos apresentados reuniam criticas no que se refere à sua adaptabilidade a uma realidade concreta. De facto, nestes domínios, a capacidade de abstracção de cada um dos participantes pode ser factor determinante de sucesso.

A solução encontrada passou por testar os conceitos num piloto envolvente e participado.

Esta prova dissipou algumas das resistências. Conceitos como sistema, plataforma, alarme, procedimento, ganharam consistência quando aplicados a uma realidade concreta.

Este exercício ajudou também a encontrar novos conceitos e afinar as relações estabelecidas entre os conceitos existentes. Entre os conceitos mais discutidos encontravam-se os conceitos de Serviço e Sistema.

• Serviço – “A collection of functionality described by one or more contracts. The service represents the unit of manageability”.

• Sistema – “Is a set of interacting or interdependent entities, real or abstract, forming an integrated whole. The concept of an 'integrated whole' can also be stated in terms of a system embodying a set of relationships which are differentiated from relationships of the set to other elements, and from relationships between an element of the set and elements not a part of the relational regime”.

Perceber o uso dos conceitos, sua instanciação e resultado na relação com os diversos elementos do portal foi determinante para a sua consolidação ou ajuste. A definição de Serviço acabou por ser simplificada em “algo que o marketing vende”. Esta frase simples permitiu uma comunicação mais fluida entre utilizadores.

Cada conceito, depois de instanciado era materializado num “artigo”. Esta concretização “material” permitiu uma identificação e sincronia explícita com a linguagem presente nos conceitos adoptados. A linguagem era comum e alinhada o que facilitava o uso do portal. O piloto foi aprovado e o entusiasmo dos participantes crescia.

10. A Consciência de Si

“Em cada organização, em cada momento, cada pessoa sabe o que está a fazer. Tem plena consciência de si. Mas a Organização, como um todo, não sabe o que cada pessoa está a fazer em cada momento” [Magalhães et. al. 2006].

Como esbater as “barreiras funcionais” e os “impeditivos humanos” na construção de uma consciência colectiva comum? Este é um dos desafios que se apresenta às organizações de hoje. Como resultado das divisões funcionais impostas pelo desenho organizacional herdado de Taylor.

As unidades organizacionais fecharam-se sobre si mesmas, criando silos que dificultam o fluxo inter-departamental. Cada grupo tem uma linguagem própria, uma sub-cultura e uma forma de se auto-organizar distinta dos demais.

A linguagem apresenta-se como um candidato chave no alinhamento organizacional. Alicerçada em comunidades virtuais, (i.e. comunidades de prática [Senge1990]), transversais aos silos organizacionais, proporciona-se um ambiente propicio à dinamização dos fluxos de informação e a transformação constante de conhecimento tácito em explicito (ver Figura 3) permitindo a criação constante do novo conhecimento, contribuindo para a consciência colectiva – a consciência do todo.

Figura 3 – Ciclos de criação de conhecimento [Nonaka 1991], retirado de [Saveri, A.2005]

Depois de embelecida a linguagem comum, o projecto evoluiu procuraram-se estabelecer os mecanismos de independência e viabilidade que, clarificando responsabilidades, dinamizassem a participação.

11. Combinando estrutura, matéria, processo e significado

Os “artigos”, instâncias de um conceito específico, deveriam garantir uma expectativa comum. Procuraram-se caracterizar os elementos que cada tipo de “artigo” deveria apresentar, garantindo um dos requisitos (capitulo 3.1 ponto 6).

Sempre que possível (dependendo da maturidade e exigência de cada conceito) definiram-se templates para os “artigos”, guiando os produtores de informação na sua actividade.

Cada unidade de “2ª linha” ficou responsável por definir, actualizar e validar procedimentos. Cada unidade de “2ª linha” está associada a um domínio de conhecimento específico, fruto da sua especialização.

As unidades de “1ª linha” ficaram responsáveis por publicar os “artigos” referentes a incidentes, garantindo a sua liberdade e independência na caracterização de um evento como incidente.

Depois de publicado, qualquer um dos participantes poderia comentar o “artigo”. Qualquer “artigo” disponibiliza um espaço para comentários, mas apenas o produtor do “artigo” teria autoridade para o alterar.

Todos os “artigos” seriam avaliados pelos utilizadores e contabilizada a sua utilização. Permitisse assim coligir informação qualitativa e quantitativa relevante. A informação, bem como os comentários, serviram de guia aos produtores e arquitectos caracterizando a utilidade e eficácia da forma de cada “artigo”.

Os participantes reconheceram a importância dos “loops de feedback” constantes, [Argyris 1977], reforçados pela informação introduzida. Re-alimentar cada “artigo” tendo por base comentários, avaliações e utilização, retirada qualquer carga emocional negativa, permitiria uma evolução constante da informação disponibilizada.

O projecto assumia-se como colaborativo, pretendendo que qualquer participante pudesse, por opção ou circunstancialmente, assumir qualquer papel definido ou emergente (i.e. papel de produtor, consumidor de informação, arquitecto). Garantiam-se assim os critérios de equidade participativa indispensáveis à cooperação[Saveri, A.2005].

12. Colaboração: Resolvendo o dilema do prisioneiro

A teoria dos jogos apresenta-se como uma ferramenta matemática com contributos importante à compreensão de fenómenos de carácter humano resultantes da interdependência do espaço de escolhas que cada individuo, e a forma como estas afectam as escolhas dos demais [Dutta, P.1999]. Constitui-se como um elemento indispensável à estratégia. Em particular, a “tragédia dos comuns” e o dilema do prisioneiro” apresentam modelos que contrapõem a lógica da decisão racional à lógica emocional inerente à natureza humana.

No dilema do prisioneiro, dois interrogados são confrontados com uma decisão: declararem-se como culpados, acusarem o outro ou assumirem-se como inocentes. Embora a solução óptima para ambos (ver Tabela 1) seja evidente, se analisada num espaço comum, as decisões individuais são influenciadas pela natureza competitiva humana (cada individuo procura o que é melhor para si em primeiro lugar). A primeira solução em que ambos se declararem como inocentes é conflituante com as opções individuais que se apresentam aparentemente mais seguras (assinaladas a itálico – correspondestes às melhores soluções para o prisioneiro 1). A percepção da melhor solução individual, mais segura num plano individual, faz com que a solução adoptada convirja para a pior solução para ambos, reforçando o Dilema.

Tabela 1 – Dilema do prisioneiro, espaço de soluções

Os resultados mostram-se negativamente surpreendentes mesmo depois de relevada a resolução óptima. A confiança apresenta-se como um factor determinante à resolução do dilema do prisioneiro.

A primeira experiência relevante de utilização do portal deu origem ao seguinte dialogo:

Rui (Elemento da 1ª Linha): Paulo1, identifiquei o incidente no serviço de Voice Mail, tenho reclamações, vou inseri-lo no portal.

Paulo1 (Project Manager): Claro Rui, é isso mesmo que está combinado.

Rui: Embora não tenha toda a informação, vou coloca-lo como associado à 2ª linha.

Paulo1: Sim, se não tens toda a informação, colocas apenas a que tens.

Paulo2: (Elemento da 2ª Linha): Paulo1, viste o que é que a primeira linha colocou no portal?

Paulo1: Sim claro, o Rui falou comigo!

Paulo2: Mas sabes que não há nenhum problema com o Voice Mail certo?

Paulo1: Sim

Paulo2: Mas não foi isso que eles escreveram! O que é que eu faço? Isto está errado! Nem somos nós que estamos a tomar conta disto, é outra 2ª linha.

Paulo1: Diz isso mesmo, esclarece onde está o Problema, o que está a ser feito e por quem!

Rui: Paulo1, acredito mesmo no Portal, isto vai funcionar. Não tinha esta informação e agora sei tudo o que preciso. Vamos a isto.

O Portal apresentava-se como a resolução óptima do dilema, a partilha da informação revela-se como mutuamente benéfica, estimulando os intervenientes a contribuírem para a sua produção.

13. Os Resultados

Num espaço de alguns meses, o portal partiu de um número inicial de 20 utilizadores para um número total superior a 160 utilizadores pertencentes à organização de suporte mas também a outras áreas da organização.

Uma vez que o projecto nasceu de forma emergente, a adopção do portal como ferramenta foi igualmente emergente, não sendo imposta a nenhuma das unidades. Procurou-se apenas reforçar os aspectos positivos associados ao seu uso.

Grande parte dos participantes usa o portal (ou os feeds RSS) como forma de acesso a uma consciência partilhada dos incidentes activos.

O processo de AoOS foi o que teve resultados com maior visibilidade no curto prazo. O número de situações que transitavam da 1ª linha ara a 2ª diminuíram em 65% o que corresponde a uma reduzindo o esforço da 2ª linha em perto de uma semana de trabalho de um recurso por mês.

O processo de AoA teve um incremento significativo com reflexos qualitativos mais difíceis de estimar no curto prazo. O número de alarmes críticos diminuiu em 35%. A capacidade de execução da 1ª linha aumentou, como reflexo, o número de vezes a que a primeira linha recorre à 2ª fora de horas diminui (embora não existam dados que permitam avaliar efectivamente essa diminuição).

A 2ª linha criou e alterou mais de 500 alarmes num processo de redefinição permanente das normas que regulam a entrega de serviço.

Ilustrando as capacidades geradoras de conhecimento que emergiram após a introdução do portal, descreve-se o seguinte exemplo:

Para um procedimento em concreto, detectou-se um número elevado de falhas na sua execução.

Consecutivamente a 1ª Linha falhava a execução do procedimento não permitindo a recuperação completa da falha em questão, potencialmente aumentando os seus impactos. No caso, o procedimento consistia na paragem e arranque de um conjunto de processos como solução temporária de recuperação.

Solicitou-se, como melhoria ao procedimento, que a 1ª linha copiasse a totalidade de comandos executados durante a execução do procedimento e enviasse essa informação por eMail.

A partir deste instante, o explicitar da acção criou mecanismos de “self-awerness” junto dos indivíduos da 1ª linha reduzindo substancialmente as falhas. O procedimento passou a ser efectuado com maior rigor.

As falhas residuais foram finalmente eliminadas após melhoria no procedimento resultante da leitura da sequência de comandos executados durante a falha.

Este discurso fluido e despido de factores emocionais, permitiu aos elementos da 1ª e 2ª linha introduzirem melhorias na sua actuação, num fluxo constante onde ambos perceberam o que tinha a melhorar.

Em situações semelhantes, era frequente a troca de acusações, “o dilema” não era resolvido não permitindo o fecho dos “loops de feedback” positivo e a introdução de melhorias.

14. Estruturando um método

A experiência apresentada permite estruturar um método que ajude à implementação de projectos colaborativos de partilha de conhecimento. Os passos aqui listados não sugerem uma metodologia em cascata mas antes uma espiral de iterações, separam-se apenas as preocupações inerentes a cada passo.

1º Passo: Definição do Problema

Mais que entender os requisitos há que entender quais são os problemas e quais são os dilemas que estão na sua origem. Esta leitura pode ser obtida a partir da análise dos processos subjacentes em conjugação com o comportamento dos indivíduos na sua excussão. Entender a estrutura organizacional confere pistas à compreensão desses dilemas.

2º Passo: Requisitos e Linguagem Comum

A instrumentação da participação colaborativa passa pela definição de uma linguagem comum. O primeiro passo de análise dos inibidores linguísticos (as distancias semânticas) pode ser facilitado na discussão de requisitos e objectivos propostos para o projecto.

3º Passo: A construção de modelos mentais de alinhamento

O alinhamento dos modelos mentais é fundamental para o sucesso da colaboração. O objectivo consiste em criar os mecanismos de feedback que garantam a sustentabilidade do projecto.

4º Passo: Garantir a independência e equidade participativa

Um critério chave para o sucesso do projecto foi a definição de participação. Os sentimentos de equidade participativa e independência foram determinantes para o seu sucesso. Em conjunto com os modelos mentais partilhados, a criação de estruturas auto-reguladas reforça a viabilidade deste tipo de projectos [De Jaegher et. al. 2007], [Parboteeah et. al. 2007].

5º Passo: Os Loops de Feedback e a partilhar resultados constante

Este passo traduz-se na inclusão de mecanismos de feedback nos processos em execução. Estes mecanismos, se bem desenhados asseguram a melhoria continua.

A partilha de resultados apresenta-se como o mecanismo último de feedback. Este feedback deve ser conseguida em duas vertentes: a primeira garantida através de mecanismos embebidos na solução; a segunda surge como resultado da partilha dos objectivos atingidos.

15. Conclusão

“Successful development of collective intelligence requires individuals to become more public in their intellectual processes and exchanges with others”. [Saveri et. al. 2005]

Como sugerem [Saver et. al. 2005] e [Parboteeah et. al. 2007] a Acção Colaborativa pode ser instrumentada através de soluções tecnológicas que estimulem a cooperação entre os indivíduos de uma organização, para alem das barreiras estabelecidas pelas unidades formais.

Estabelecer uma linguagem comum apresenta-se como pilar do alinhamento e troca de conhecimento, indispensáveis à dinâmica colaborativa tal como sugerem [Magalhães 1999] e [Capra 2002] a partir da sua síntese de Giddens, Habermas entre outros. As Ontologias apresentam-se como um instrumento capaz de articular a captura de conhecimento e simultaneamente alinhar o discurso da organização.

No decorrer do caso prático, a comunicação do grupo passou a utilizar o portal, os seus “artigos” e conceitos como referência. A comunicação é explicitada através da inclusão de links

para “artigos” específicos ou recorrendo a conceitos já definidos. Obtém-se assim simultaneamente Memória e Significado colectivos.

A Organização beneficia da quebra das fronteiras da Estrutura tradicional. A cooperação passa a ser veiculada através do fluxo de Processos. Garantindo círculos de feedback constante e permitindo a captura de conhecimento inerente à emergência de soluções resultante da gestão de excepções e erros associada à sua execução. Reforçam-se as comunidades de uma mesma prática, [Senge 1990], mas também as que partilham a execução de um fluxo de actividades associadas a um mesmo processo.

No caso apresentado as unidades de 1ª e 2ª linha passaram a resolver os dilemas associados à partilha de informação, entendendo os mútuos benefícios inerentes. Salienta-se a importância da equidade participativa como garante do clima de confiança indispensáveis à cooperação.

Por fim ferramentas Wiki e a sua evolução com os wiki-semantics apresentam-se como importantes na concretização prática destes desafios.

Este caso deixa desafios diversos e interessantes para futuras investigações:

• Como melhorar a gestão de excepções articulando as vertentes Gestão de Processos e Workflows explorada por [Mourão 2007] com a informação/conhecimento de suporte (neste caso presentes em Wikis). A experiência efectuada a partir da interligação de alarmes HP-OV com Procedimentos de AoA deixa antever resultados interessantes.

• Como comparar a distância semântica entre as ontologias de discurso presentes na organização e a proposta nos seus processos.

• A Linguagem e a Teoria dos Jogos: como detectar o “Dilema do Prisioneiro”, a “Tragédia dos Comuns” na semântica do discurso da organização, instrumentando a sua resolução.

16. Referências

Nonaka, I., “The knowledge-Creating Company”, Harvard Business Review, 1991

Porter, M., Millar, V. “How Information Gives You Competitive Advantage”; Harvard Business Review; 1985

Lindgren, R., Henfridsson, O., Schultze, U., “Design Principales for Competence Management Systems: A synthesis of an Action Research Study”, MIS Quarterly, 2004

Argyris, C., “Double Loop Learning in Organizations”, Harvard Business Review, 1977

Senge, P.; “The Fifth Discipline: The Art & Practice of the Learning Organization”, Doubleday Currency, 1990.

Dutta, P.; “Strategies and Games”, The MIT Press,1999

Mourão, H., “Supporting Effective Unexpected Exception Handling in Workflow Management Systems within Organizational Contexts”; Universidade Nova de Lisboa / Faculdade de Ciencias, 2007

Parboteeah, P., Jackson, T. W., “An Autopoietic Framework for Organizational Learning”, Wiley InterScience, 2007

Saveri, A., Rheingold, H., “Rapid Decision Making for Complex Issues: How Technologies of Cooperation can help”; Institure for the Future, Publicação on-line: www.iftf.org; 2005

McGuiness, D., “Ontologies Come of Age”, W3C consortium Talks, 2000

Uschold, M., Gruninger, M., “Ontologies: Principles, Methods and Applications”, Knowledge Engineering Review, 1996

Fernández, M., Gómez-Pérez, A., Sierra, J., Sierra, A., "Building a Chemical Ontology Using Methontology and the Ontology Designe Environment”, IEEE, 1999

De Jaegher, H. Di Paolo, E., “Participatory sense-making An enactive approach to social cognition”, Springer Science, 2007

Magalhães, R., Tribolet, J.; “Engenharia Organizacional: Das Partes ao Todo e do Todo às Partes na Dialéctica entre Pessoas e Sistemas”, S.l.: Forthcoming, 2006

Magalhães, R.; “The Organizational Implementation of Information Systems: towards a new theory; London School of Economics”, The London School of Economics, 1999

Capra, F., “The Hidden Connections”, Anchor Books, 2002