Descentralizando TI com a adoc¸˜ao do End-User Development:
dois estudos de caso
Claudia de O. Melo1, Rejane M. da C. Figueiredo2, Elaine Venson2
1Departamento de Ciˆencia da Computac¸˜ao (CIC-UnB) Bras´ılia – DF – Brasil
2Faculdade do Gama (FGA-UnB) Bras´ılia – DF – Brasil
{claudia.melo,rejanecosta,elainevenson}@unb.br
Abstract. Context: Digital transformation is changing the industry and the way we use Information Technology (IT). Software is mostly written by end-users with business knowledge willing to achieve theirs goals through IT, although established IT governance is not always appropriate. Understanding how to organize the decentralization of the IT function to prepare the organization for the challenges and opportunities of the 21st century is key. Goal: This paper aims to investigate, from a socio-technical perspective, how organizations decentralize IT through End-User Development (EUD). Method: Two case studies have been conducted in organizations trying to decentralize IT through EUD for, at least, 3 years. A conceptual framework has been described to allow case analysis. Results: IT governancematurity was an important factor that enabled decentralization through the EUD, although both cases did not reach a high degree of decentralization. Shadow IT remained in both cases.
Both organizations were not focused on innovation during the decentralization initiatives, although this is a fundamental vision of for the IT function in the 21st century.
Resumo. Contexto: A transformac¸˜ao digital est´a mudando a ind´ustria e a maneira como usamos a tecnologia da informac¸˜ao (TI). A maior parte dos programas j´a s˜ao escritos por usu´arios finais com conhecimento do neg´ocio que precisam cumprir objetivos com o uso da TI, embora a governanc¸a estabelecida nem sempre seja adequada. A compreens˜ao de como organizar a descentralizac¸˜ao da func¸˜ao de TI para usu´arios finais, de modo a preparar a organizac¸˜ao para os desafios e oportunidades do s´eculo 21, torna-se chave. Objetivo: Este trabalho tem como objetivo investigar, sob uma ´otica socio-t´ecnica, como organizac¸˜oes descentralizam a TI por meio de End-User Development (EUD). M´etodo: Foram conduzidos dois estudos de caso em organizac¸˜oes que buscam a descentralizac¸˜ao por EUD h´a pelo menos 3 anos.
Foi descrito um framework conceitual para an´alise dos casos. Resultados: A maturidade pr´evia em governanc¸a da TI foi fator importante na capacidade de descentralizac¸˜ao atrav´es de EUD, embora ambos casos n˜ao tenham atingido alto grau de descentralizac¸˜ao. A TI sombra permaneceu em ambos os casos.
Ambas organizac¸˜oes n˜ao demonstraram buscar inovac¸˜ao com as iniciativas de descentralizac¸˜ao, embora esta seja uma vis˜ao fundamental da func¸˜ao de TI no s´eculo 21.
1. Introduc¸˜ao
A transformac¸˜ao digital est´a mudando a ind´ustria e a maneira como usamos a tecnologia da informac¸˜ao (TI) [Bygstad 2016]. Duas tendˆencias atuais geram as forc¸as dessa transformac¸˜ao. Por um lado, os sistemas de TI est˜ao cada vez maiores e mais interconectados. Por outro, o uso crescente de equipamentos pessoais m´oveis na vida profissional vem desafiando a hegemonia dos departamentos de TI. Os movimentos
“traga seu pr´oprio dispositivo” e “fac¸a vocˆe mesmo” est˜ao se tornando rapidamente um fato aceit´avel na vida corporativa, cuja tendˆencia ´e denominada consumerizac¸˜ao e gera um conjunto de novos desafios sobre uso, seguranc¸a e governanc¸a de TI [Niehaves et al. 2012, K¨offer et al. 2014].
De fato, a maior parte dos programas n˜ao s˜ao escritos por profissionais de desenvolvimento de software, mas por pessoas com conhecimento do neg´ocio que precisam cumprir objetivos com o uso da TI [Ko et al. 2011], com ou sem o conhecimento e suporte do departamento de TI. Quando desenvolvidos sem a conscientizac¸˜ao, aceitac¸˜ao, conhecimento ou suporte de um departamento de TI, s˜ao denominados “TI invis´ıvel”ou “TI Sombra”(Shadow IT) [Silic and Back 2014]. J´a o Desenvolvimento por Usu´ario Final (End-User Development, ou EUD) ocorre quando h´a o desenvolvimento, modificac¸˜ao ou aperfeic¸oamento de aplicac¸˜oes de sistemas de informac¸˜ao por usu´arios finais para uso individual, departamental ou organizacional [Barker and Fiedler 2011], com conhecimento e suporte do departamento de TI [Zimmermann et al. 2014].
Se antes esses usu´arios j´a desenvolviam grande parte das soluc¸˜oes, agora s˜ao vistos como centrais no novo regime de conhecimento baseado em inovac¸˜ao digital [Bygstad 2016]. De fato, a inovac¸˜ao esperada na Economia Digital depende dessa r´apida apropriac¸˜ao tecnol´ogica por parte de usu´arios comuns, dado que a inovac¸˜ao pode surgir a partir de qualquer pessoa. Soluc¸˜oes criadas por usu´arios finais, antes vistas como um problema a ser gerenciado pelas organizac¸˜oes, tornam-se agora um recurso estrat´egico [Dittrich et al. 2017]. A tecnologia e todos seus stakeholders passaram a ter uma func¸˜ao e conjunto de competˆencias muito mais importantes, pois geram novo valor de neg´ocio [Andriole 2015, K¨offer et al. 2015].
A transformac¸˜ao digital vem mudando a forma como a governanc¸a ´e definida e gerenciada em muitas organizac¸˜oes [Andriole 2015]. At´e o s´eculo 20, a gest˜ao tecnol´ogica se concentrou majoritariamente em definic¸˜ao de padr˜oes e gerenciamento centralizado. Na economia do s´eculo 21, dirigida pela inovac¸˜ao digital, a ˆenfase nesse paradigma perdeu o sentido. A TI n˜ao ´e mais propriedade de um departamento central, mas uma func¸˜ao inerente a toda a organizac¸˜ao. Assim, algumas organizac¸˜oes est˜ao experimentando a descentralizac¸˜ao da gest˜ao de TI, passando a modelos federados e at´e participat´orios [Andriole 2015].
A compreens˜ao de como descentralizar a func¸˜ao de TI de modo a preparar a organizac¸˜ao para os desafios e oportunidades do s´eculo 21 torna-se chave. Pesquisas recentes investigam diferentes aspectos sobre modelos de governanc¸a do EUD, assim como do fenˆomeno da TI Sombra, sob o ponto de vista de alocac¸˜ao das responsabilidades [Winkler and Brown 2013, Zimmermann et al. 2016], alinhamento entre usu´arios, TI e organizac¸˜ao [Chua et al. 2014], colaborac¸˜ao [Ferneley 2007] e relac¸˜oes de poder e risco [F¨urstenau et al. 2017]. Um aspecto fundamental de investigac¸˜ao para apoiar organizac¸˜oes que buscam descentralizar TI atrav´es de EUD ´e compreender as interac¸˜oes
entre os diferentesstakeholderse tecnologias envolvidos para o sucesso de uma iniciativa em n´ıvel organizacional.
Este trabalho tem como objetivo investigar, sob uma ´otica socio-t´ecnica, a quest˜ao de pesquisa (QP) “Como organizac¸˜oes descentralizam a TI por meio de EUD?”. Para responder `a quest˜ao, foram conduzidos dois estudos de caso em organizac¸˜oes que buscam ampliar sua capacidade de lidar com TI com a adoc¸˜ao da descentralizac¸˜ao por EUD h´a pelo menos 3 anos. Para analisar os casos, derivamos um framework conceitual baseado em um paradigma socio-t´ecnico de meta-design de EUD proposta em [Fischer et al. 2004] e tamb´em nos mecanismos gerais de governanc¸a de TI propostos em [Weill and Ross 2004].
As principais contribuic¸˜oes deste artigo s˜ao:
• A descric¸˜ao dos conceitos relacionados ao EUD, contextualizando-os em uma nova era de Governanc¸a de TI, na Sec¸˜ao 2;
• A apresentac¸˜ao de umframework conceitual para analisar a descentralizac¸˜ao de TI pela adoc¸˜ao de EUD, derivado de dois trabalhos s´olidos da ´area de governanc¸a e de EUD, na Sec¸˜ao 3;
• O uso doframeworkconceitual para an´alise de dois estudos de caso para investigar como organizac¸˜oes descentralizam a TI por meio de EUD, na Sec¸˜ao 4;
• A descric¸˜ao da abordagem de descentralizac¸˜ao utilizada por cada uma das organizac¸˜oes investigadas e uma s´ıntese comparada aoframework conceitual, na Sec¸˜ao 5;
• Uma discuss˜ao sobre os elementos relevantes encontrados nos dois casos frente ao framework conceitual e a literatura, na Sec¸˜ao 6.
2. Desenvolvimento te´orico
2.1. Desenvolvimento por Usu´ario Final (EUD)
O desenvolvimento por usu´ario final (End-User Development - EUD) ´e realizado por usu´arios finais e n˜ao-especialistas em programac¸˜ao de aplicac¸˜oes que desenvolvem ou adaptam sistemas de acordo com suas necessidades, sejam profissionais, educacionais ou para lazer [Lieberman et al. 2006]. EUD ´e, mais especificamente, o desenvolvimento, modificac¸˜ao ou aperfeic¸oamento de aplicac¸˜oes de sistemas de informac¸˜ao por usu´arios finais para uso individual, departamental ou organizacional [Barker and Fiedler 2011].
Usu´arios finais desenvolvedores podem criar software em uma variedade de dom´ınios, de aplicac¸˜oes dom´esticas a aplicac¸˜oes financeiras, cient´ıficas, administrativas ou de recursos humanos [Figueiredo et al. 2017]. As atividades e ferramentas utilizadas para o desenvolvimento das soluc¸˜oes de software por usu´arios s˜ao diferentes, conforme os objetivos dos tipos de usu´arios.
Outras abordagens similares a EUD s˜aoRapid Application Development (RAD) e Low Code. Esse ´ultimo termo vem sendo cunhado recentemente pela ind´ustria para caracterizar plataformas que permitam a entrega r´apida de aplicativos de neg´ocios com um m´ınimo de codificac¸˜ao manual e investimento inicial de configurac¸˜ao, treinamento e implantac¸˜ao [Richardson and Rymer 2016].
O objetivo de se adotar a abordagem EUD como estrat´egia organizacional, que inclui processos e ferramentas, ´e reduzir o fardo de aprendizagem e, ao mesmo tempo,
dar instrumentos poderosos aos funcion´arios para lidar com in´umeros tipos de problemas envolvendo demanda de TI [Fischer et al. 2004]. Dado que algum fardo de aprendizagem sempre estar´a presente, as ferramentas precisam motivar seus usu´arios. O sucesso do EUD depende de um equil´ıbrio entre a motivac¸˜ao do usu´ario, ferramentas efetivas e suporte de gerenciamento.
As pesquisas da comunidade de EUD tamb´em descrevem uma transformac¸˜ao cultural fundamental no papel do usu´ario, que deixa de ser um consumidor passivo de produtos produzidos por outros, para um usu´ario empoderado para participar ativamente de atividades de car´ater significativo [von Hippel 2005, Fischer 2009, Maceli 2017]. EUD
´e componente essencial dessa transformac¸˜ao. Seu impacto, de fato, pode ser muito mais amplo: essa transformac¸˜ao representa uma mudanc¸a e uma nova oportunidade para a produc¸˜ao social, para a colaborac¸˜ao em massa, para a vida c´ıvica e pol´ıtica e para a educac¸˜ao [Fischer 2009].
A adoc¸˜ao de EUD tamb´em envolve alguns riscos. Em revis˜ao de literatura conduzida por [Figueiredo et al. 2017], foram identificados os principais riscos da adoc¸˜ao de EUD. Dentre eles est˜ao a baixa qualidade das aplicac¸˜oes desenvolvidas, perda do controle do desenvolvimento da aplicac¸˜ao, utilizac¸˜ao ineficaz dos recursos, ameac¸a `a seguranc¸a dos dados, ameac¸a `a integridade dos dados, resolver o problema errado e abandono da aplicac¸˜ao pelos usu´arios utilizadores.
Na revis˜ao de estado da arte de EUD, [Ko et al. 2011] apontam que alguns trabalhos recentes sobre o EUD est˜ao se movendo em v´arias direc¸˜oes ao mesmo tempo:
para mais plataformas e paradigmas, incluindo a web e dispositivos m´oveis; para explorar boas pr´aticas da engenharia de software, incluindo especificac¸˜ao e reutilizac¸˜ao de c´odigo;
para um foco mais amplo em dom´ınios de aplicac¸˜ao, ao inv´es de paradigma de linguagem
´unico. Al´em disso, os autores afirmam que a Web tem se tornado uma plataforma dominante para a aprendizagem da programac¸˜ao pelos usu´arios finais, bem como, para apoiar suas atividades de desenvolvimento do EUD.
2.2. Governanc¸a de TI na Era Digital
A governanc¸a de TI pode ser definida como “a distribuic¸˜ao de direitos e responsabilidades de decis˜ao de TI entre as diferentes partes interessadas na empresa e define os procedimentos e mecanismos para elaborar e monitorar decis˜oes estrat´egicas de TI”
[Peterson 2004]. Ela define os pap´eis e responsabilidades para tomar decis˜oes relacionadas `a TI, al´em de processos efetivos de tomada de decis˜ao e mecanismos de avaliac¸˜ao de desempenho.
No entanto, na era digital, produtos e servic¸os tornam-se cada vez mais digitalizados, desfigurando os limites entre os processos de TI e neg´ocios (por exemplo, marketing, vendas, fabricac¸˜ao) [Bharadwaj et al. 2013]. Muitas decis˜oes, portanto, ocorrem em conjunto em equipes multifuncionais em oposic¸˜ao `a tomada de decis˜ao autˆonoma de n´ıvel funcional ou bilateral. O pensamento da func¸˜ao de TI submetida
`a autoridade de neg´ocios muda `a medida que ela torna-se a forma comum de entregar produtos e servic¸os [DeLone et al. 2017].
A alta velocidade do desenvolvimento tecnol´ogico incentiva as empresas a desenvolver princ´ıpios de governanc¸a para simplificar e acelerar os processos de tomada de decis˜ao relacionados `a TI. Essas tendˆencias digitais sugerem que os modelos de
governanc¸a de TI baseados na separac¸˜ao distinta das responsabilidades funcionais e na tomada de decis˜ao inerentemente hier´arquica talvez precisem ser revisados [DeLone et al. 2017].
A governanc¸a est´a mudando, o controle ´e um conceito que se transforma em colaborac¸˜ao e participac¸˜ao, e a governanc¸a participativa substituir´a as r´ıgidas estruturas e processos de governanc¸a convencionais do s´eculo 20 e estruturas ainda mais abertas e federadas do in´ıcio do s´eculo XXI. A governanc¸a participat´oria reconhece a expans˜ao do n´umero de stakeholders da governanc¸a para fora da organizac¸˜ao, a comoditizac¸˜ao da tecnologia, a consumerizac¸˜ao e a crescente pr´atica de terceirizac¸˜ao de tecnologia operacional, estrat´egica e emergente. A literatura tamb´em sugere que a nova oportunidade de alinhamento da tecnologia empresarial ´e a partir da governanc¸a participat´oria [Andriole 2015].
3. Framework conceitual para analisar descentralizac¸˜ao de TI pela abordagem EUD
Para que seja poss´ıvel descentralizar a func¸˜ao de TI pela abordagem EUD, ´e necess´ario investigar tanto os mecanismos de descentralizac¸˜ao da governanc¸a quanto os mecanismos habilitadores de EUD. EUD j´a pressup˜oe algum n´ıvel de descentralizac¸˜ao, visto que se espera o maior empoderamento dos usu´arios finais. Esse empoderamento gerar´a conflitos com as estruturas de governanc¸a existentes, que podem ser frut´ıferos e gerar novas estruturas adaptadas ou n˜ao.
Para analisar as dinˆamicas de descentralizac¸˜ao de TI atrav´es de EUD, derivou-se um framework conceitual baseado em dois trabalhos s´olidos da ´area de governanc¸a e de EUD. A base do modelo ´e dada pela vis˜ao s´ocio-t´ecnica de EUD proposta em [Fischer et al. 2004]. Oframework tamb´em inclui os mecanismos gerais de governanc¸a de TI propostos em [Weill and Ross 2004].
Oframeworkdescreve as diversas forc¸as que atuam na organizac¸˜ao em busca do sucesso de iniciativas EUD (Figura 1), detalhadas nas pr´oximas sec¸˜oes.
3.1. Motivadores do usu´ario
Compreendem a capacitac¸˜ao para poder completar um trabalho de forma mais eficaz, a velocidade de desenvolvimento, a flexibilidade e o controle local para que a programac¸˜ao possa ser “sob demanda”. Um dos benef´ıcios ´e a eliminac¸˜ao de poss´ıveis erros de comunicac¸˜ao de requisitos para engenheiros de software especializados, evitando assim a frustrac¸˜ao com o servic¸o prestado pelo departamento de TI.
Hist´orias de sucesso podem criar capital motivacional para ajudar os usu´arios sobre a curva de aprendizado at´e que os benef´ıcios reais cheguem na forma de aplicativos de trabalho. A motivac¸˜ao do usu´ario deve ser encorajada durante os est´agios iniciais da adoc¸˜ao por meio de suporte da gest˜ao, treinamento e forc¸as-tarefa para difundir melhores pr´aticas e conhecimentos especializados. Isso remedia custos dos usu´arios, como selecionar a tecnologia apropriada, instal´a-la e aprendˆe-la, program´a-la e depur´a-la.
3.2. Quest˜oes Gerenciais e Contextuais
Uma s´erie de quest˜oes de contexto e gerenciamento influenciam o equil´ıbrio entre custos e benef´ıcios. Por exemplo, a abordagem EUD pode ser perigosa em dom´ınios de seguranc¸a
Figura 1. Framework conceitual adaptado de [Fischer et al. 2004] e [Weill and Ross 2004]
cr´ıtica, onde o software precisa ser confi´avel e preciso. Os custos do usu´ario podem ser afetados significativamente pela escala e complexidade do dom´ınio, portanto, dom´ınios mais seguros e menos complexos devem ser selecionados para EUD. A mudanc¸a de dom´ınio pode ser um motivador para a adoc¸˜ao do EUD, uma vez que os usu´arios finais podem responder aos requisitos em r´apida evoluc¸˜ao, mais rapidamente do que o desenvolvimento tradicional. No entanto, mudanc¸as r´apidas podem levar a um software descart´avel e a um esforc¸o de desenvolvimento perdido.
As quest˜oes de gest˜ao incluem riscos associados `a EUD, percebidos pelos departamentos de TI como a criac¸˜ao de software n˜ao confi´avel e n˜ao sustent´avel. Outros riscos s˜ao informac¸˜oes imprecisas, seguranc¸a com maior exposic¸˜ao `a ataques. O conflito entre o gerenciamento de TI e os usu´arios finais sobre o poder, autoridade e controle de sistemas de TI pode ser uma forc¸a produtiva para a mudanc¸a ou pode levar `a interrupc¸˜ao, desconfianc¸a e falha.
Padr˜oes e controle de usu´arios finais levam a um desenvolvimento mais econˆomico e menos desperd´ıcio de software n˜ao confi´avel [Fischer et al. 2004]. No entanto, o controle r´ıgido pode gerar ressentimento entre os usu´arios finais. O conflito de controle e poder entre usu´arios e departamento de TI sempre vai existir. No entanto, interac¸˜oes construtivas visando apoiar e treinar usu´arios promove o sucesso das ac¸˜oes, encoraja a responsabilidade das partes e possibilita o controle por lideranc¸a.
3.2.1. Mecanismos de governanc¸a de TI
O modelo original de Fischer et al. [Fischer et al. 2004] considera poder, controle e responsabilidade parte das quest˜oes gerenciais, mas n˜ao os detalham. Por serem de vital importˆancia no entendimento da descentralizac¸˜ao da func¸˜ao de TI, oframeworkincorpora os mecanismos de governanc¸a de TI [Weill and Ross 2004, Haes and Grembergen 2009]
que n˜ao apenas detalham poder, controle e responsabilidade, mas tamb´em s˜ao considerados necess´arios para uma governanc¸a bem sucedida [Frey and Buxmann 2011, Ping-Ju Wu et al. 2015].
Mecanismos de governanc¸a objetivam encorajar a congruˆencia com a miss˜ao, a estrat´egia, os valores, as normas e a cultura da organizac¸˜ao, criando condic¸˜oes favor´aveis para os comportamentos de TI desejados. A existˆencia desses mecanismos ´e muitas vezes indicativo de uma capacidade sofisticada de gerenciamento de TI e de neg´ocios [Karimi et al. 2000, Bradley et al. 2012, Ping-Ju Wu et al. 2015].
De modo geral, pode-se entender que a governanc¸a bem-sucedida de TI implementa trˆes tipos diferentes de mecanismos: 1) estruturas de tomada de decis˜ao, 2) processos de alinhamento e 3) abordagens de comunicac¸˜ao [Weill and Ross 2004].
Estruturas de tomada de decis˜ao referem-se ao grau em que a organizac¸˜ao estabeleceu unidades organizacionais e func¸˜oes respons´aveis pela tomada de decis˜oes de TI, como comitˆes e pap´eis que localizam as responsabilidades de tomada de decis˜ao [Weill and Ross 2004, Haes and Grembergen 2009]. Nesse sentido, oframework considera trˆes poss´ıveis classificac¸˜oes de como organizac¸˜oes tomam decis˜oes de forma mais ou menos centralizada:centralizado, federado, descentralizado e participat´orio.
Em organizac¸˜oes de TI centralizadas, os direitos de decis˜ao envolvidos na aquisic¸˜ao, implantac¸˜ao e suporte de tecnologia pertencem a um grupo central que reporta a um executivo corporativo. Em organizac¸˜oes federadas, os direitos s˜ao coordenados em todo o grupo corporativo de TI, as unidades de neg´ocios e at´e mesmo func¸˜oes corporativas espec´ıficas [Frey and Buxmann 2011, Andriole 2015]. J´a nas organizac¸˜oes descentralizadas, os direitos de decis˜ao s˜ao compartilhados em toda a empresa e unidades de neg´ocios. Por fim, em organizac¸˜oesparticipat´orias, a tomada de decis˜oes inclui stakeholders externos `a organizac¸˜ao, como fornecedores de hardware, software e servic¸os, parceiros e fornecedores, ou qualquer pessoa que contribua para o sucesso da organizac¸˜ao. Esse seria o maior grau de descentralizac¸˜ao considerado noframework.
Processos de alinhamentoreferem-se ao grau em que a organizac¸˜ao estabeleceu processos formais para monitorar e garantir que as pol´ıticas de TI sejam consistentes com as necessidades do neg´ocio. Acordos de n´ıvel de servic¸o e monitoramento do valor gerado s˜ao exemplos de como as organizac¸˜oes se forc¸am a avaliar continuamente o retorno real obtido atrav´es da TI [Weill and Ross 2005].
As abordagens de comunicac¸˜ao referem-se ao grau em que a organizac¸˜ao estabeleceu canais para garantir comunicac¸˜ao e disseminac¸˜ao dos princ´ıpios de governanc¸a de TI. Maior comunicac¸˜ao geralmente significa mais governanc¸a efetiva [Weill and Ross 2005]. A administrac¸˜ao pode comunicar os processos de governanc¸a de v´arias formas: an´uncios gerais; a instituic¸˜ao de comiss˜oes formais; comunicac¸˜oes regulares do escrit´orio do CIO ou do escrit´orio de governanc¸a de TI; sess˜oes individuais;
Intranets etc.
3.3. Fatores cr´ıticos de sucesso
Os fatores de sucesso dependem do dom´ınio. Em uma cultura de usu´arios finais motivados e baixa influˆencia gerencial, o sucesso ´e simplesmente uma quest˜ao de usu´arios levando o desenvolvimento em suas pr´oprias m˜aos, muitas vezes usando linguagens de programac¸˜ao
padr˜ao. No entanto, na maioria dos dom´ınios empresariais, o treinamento, o suporte t´ecnico e de gerenciamento s˜ao vitais para ajudar o EUD a prosperar.
Em uma cultura de cooperac¸˜ao, h´a compartilhamento de responsabilidade pelo desenvolvimento de soluc¸˜oes precisas e efetivas. Especialistas locais da comunidade de usu´arios finais disseminam conhecimentos e conselhos, embora os usu´arios avanc¸ados possam ser propensos a migrar para o lado errado do “n´os” e “eles” (departamento de TI). Por fim, a tecnologia deve fornecer uma integrac¸˜ao f´acil com outros sistemas de informac¸˜ao e suporte otimizado para tarefas EUD.
4. M´etodo de Pesquisa
Para investigar nossa quest˜ao de pesquisa “Como organizac¸˜oes descentralizam a TI por meio de EUD?”, foram realizados dois estudos de caso [Yin 2009] em organizac¸˜oes p´ublicas federais. Estudos de caso s˜ao adequados para investigac¸˜oes socio-t´ecnicas [Benbasat et al. 1987, Voss et al. 2002].
O crit´erio para selec¸˜ao dos casos foi identificar organizac¸˜oes que buscavam a descentralizac¸˜ao pela adoc¸˜ao do EUD h´a pelo menos 3 anos. Assim, seria poss´ıvel analisar as estruturas existentes e experiˆencias concretas de descentralizac¸˜ao tanto do ponto de vista de organizac¸˜ao quanto do ponto de vista dos usu´arios desenvolvedores.
Foram projetados dois estudos caso hol´ısticos, onde a unidade de an´alise ´e a organizac¸˜ao.
Os principais m´etodos de coleta de dados foram entrevistas semi-estruturadas (Apˆendice A), al´em de question´arios e an´alise de documentos disponibilizados pelas organizac¸˜oes. Os dados foram coletados entre Setembro de 2016 e Setembro de 2017. As entrevistas buscaram investigar o cen´ario geral de descentralizac¸˜ao por meio de EUD. As pesquisadoras tˆem experiˆencia conduzindo entrevistas de campo no contexto cient´ıfico, tamb´em com experiˆencia em conduc¸˜ao de entrevistas para elicitac¸˜ao de requisitos em empresas privadas. Na organizac¸˜ao A, foram realizadas m´ultiplas entrevistas com dois profissionais l´ıderes de ´area ao longo do per´ıodo de coleta de dados. Na organizac¸˜ao B, foram realizadas m´ultiplas entrevistas com dois profissionais l´ıderes de ´area, al´em de entrevista com 6 profissionais que atuam no desenvolvimento dos sistemas atrav´es de Oracle Apex (inicialmente destinado ao EUD).
Os question´arios foram realizados ap´os as entrevistas para detalhar ou confirmar dados obtidos nas entrevistas e foram enviados para a chefia da ´area respons´avel pela iniciativa EUD. Os documentos compreenderam, principalmente, site do processo, apresentac¸˜oes, relat´orios e, portarias, em sua maioria documentos abertos ao p´ublico.
Os dados obtidos pelos trˆes tipos de m´etodo de coleta foram triangulados durante a realizac¸˜ao da an´alise. Quando havia d´uvida sobre dados de entrevista ou documentos, ou mesmo conflito entre informac¸˜oes, novas entrevistas eram agendadas ou um question´ario era enviado por e-mail.
O m´etodo de an´alise dos casos foi o de adequac¸˜ao ao padr˜ao (pattern matching) [Trochim 1989], onde os padr˜oes observados nos dados coletados (fundamentalmente emp´ıricos) s˜ao comparados com os padr˜oes previstos, ou seja, peloframeworkconceitual proposto (Figura 1). Se os padr˜oes coincidem, os resultados podem ajudar no aumento da validade interna do estudo.
5. Resultados
Nesta sec¸˜ao os principais resultados dos estudos de caso s˜ao apresentados. A Tabela 1 descreve o perfil das organizac¸˜oes estudadas, onde cada organizac¸˜ao ´e a unidade de an´alise do caso. Em seguida, os casos s˜ao descritos individualmente.
Tabela 1. Perfil das organizac¸ ˜oes
Caracter´ısticas Organizac¸˜ao (Caso) A Organizac¸˜ao (Caso) B
Tipo P´ublica P´ublica
Ind ´ustria Governo Governo
Estrutura organizacional
Hier´arquica Hier´arquica
Estrutura
organizacional de TI
Departamento de TI e TI departamental
Departamento de TI e TI departamental
Tamanho da TI 136 funcion´arios, 79 estagi´arios e 24 terceiros
153 funcion´arios e 4 estagi´arios
Descentralizac¸˜ao por EUD (In´ıcio)
2007 2012
N ´umero atual de pessoas envolvidas
Departamento de TI: 3. ´Areas de Neg´ocio: 73. Estagi´arios: 47
Departamento de TI: 15 pessoas (10 alocados na TI corporativa e 5 nas ´areas de neg´ocio). ´Areas de Neg´ocio: n˜ao h´a registro (ocorrem por excec¸˜ao).
Estagi´arios: inicialmente 8, atualmente 0
Perfil dos usu´arios desenvolvedores
Funcion´arios da ´area de neg´ocio com formac¸˜ao ou alguma experiˆencia pr´evia em TI.
Estagi´arios de TI.
Funcion´arios da ´area de TI.
Estagi´arios de TI.
Perfil dos sistemas desenvolvidos
Sistemas cadastrais para usu´arios internos e externos `a organizac¸˜ao.
Sistemas cadastrais para usu´arios internos e externos `a organizac¸˜ao.
Tecnologia de desenvolvimento
Oracle Apex Oracle Apex
N ´umero de sistemas desenvolvidos
mais de 200, 141 em operac¸˜ao 38
5.1. Caso A
5.1.1. Motivadores do usu´ario
A organizac¸˜ao A reconhece que sempre houve usu´arios desenvolvedores para soluc¸˜oes de problemas locais com ferramentas de escrit´orio ou at´e mesmo com linguagens de programac¸˜ao. Um dos principais motivos ´e o desequil´ıbrio entre os recursos de TI dispon´ıveis e a alta demanda das ´areas clientes.
Em 2007, com a priorizac¸˜ao de um sistema corporativo, a organizac¸˜ao reconheceu a iniciativa e participac¸˜ao das ´areas de neg´ocio na construc¸˜ao de soluc¸˜oes de TI departamentais e criou um programa baseado nos conceitos de EUD para apoi´a-las.
Foi definida uma abordagem EUD inicial para a organizac¸˜ao, baseada na alocac¸˜ao de estagi´arios de cursos da ´area de computac¸˜ao pelas ´areas de neg´ocio que adotavam a abordagem EUD, para apoiarem a construc¸˜ao de sistemas de informac¸˜ao.
Com o movimento de descentralizac¸˜ao da tecnologia pela adoc¸˜ao do EUD, qualquer ´area de neg´ocio desenvolve soluc¸˜oes, seguindo os padr˜oes estabelecidos pela Unidade EUD do departamento de TI. Caso contr´ario, ser´a considerado TI Sombra, o que ainda ocorre na organizac¸˜ao. Todas as ac¸˜oes e iniciativas de EUD no ´org˜ao s˜ao reguladas por uma pol´ıtica de Governanc¸a de TI.
Os funcion´arios com competˆencias t´ecnicas desenvolvem e podem contar com o apoio da Unidade EUD. Para apoiar os funcion´arios com pouco conhecimento t´ecnico, estagi´arios de TI passaram a ser selecionados e treinados pela unidade respons´avel pelo EUD na organizac¸˜ao. No entanto, a contratac¸˜ao continua sendo de responsabilidade das unidades de neg´ocio. Essa estrat´egia ´e utilizada quando n˜ao h´a uma pessoa interessada ou apta em desenvolver aplicac¸˜oes.
Um dos entrevistados da organizac¸˜ao comenta sobre o grau de empoderamento, flexibilidade e rapidez dos usu´arios evolu´ırem suas pr´oprias aplicac¸˜oes:
”No caso de demandas de manutenc¸˜ao, a pr´opria ´area desenvolvedora da soluc¸˜ao fica respons´avel por implementar as alterac¸˜oes. Mudanc¸as em sistemas devem ter a anuˆencia do respectivo gestor da soluc¸˜ao [...]
temos visto que as aplicac¸˜oes desenvolvidas na ferramenta Oracle Apex s˜ao implementadas em intervalos de poucos minutos ou mesmo at´e trˆes ou 4 anos, conforme a complexidade da aplicac¸˜ao [...] vejo que as unidades s˜ao satisfeitas com seus sistemas e ganham independˆencia e facilidade para desenvolver e evoluir seus sistemas. Principalmente unidades que nunca eram priorizadas no Plano de TI”
Desde 2007, mais de 200 sistemas foram desenvolvidos nessa abordagem, sendo que cerca de 141 est˜ao em operac¸˜ao.
5.1.2. Quest˜oes Gerenciais e Contextuais
Inicialmente, as soluc¸˜oes desenvolvidas por usu´arios desenvolvedores apresentavam qualidade question´avel. Em geral, possu´ıam apenas o c´odigo-fonte, com ind´ıcios de falta de padr˜oes, crit´erios de projeto ou testes de qualidade, o que comprometia a consistˆencia dos resultados, assim como a seguranc¸a da informac¸˜ao.
O departamento de TI n˜ao participava ou n˜ao tinha conhecimento do desenvolvimento, que ocorria dada a dificuldade em atender as demandas pontuais das diversas ´areas clientes. Quando as aplicac¸˜oes desenvolvidas por usu´arios finais precisavam ser evolu´ıdas, em geral por necessidades do neg´ocio, ou quando paravam de funcionar, muitas vezes a responsabilidade era transferida para o departamento de TI. A situac¸˜ao obviamente impactava o planejamento, assim como a produtividade, do departamento de TI, pois o escopo de atendimento crescia sem previsibilidade.
Em 2007, a organizac¸˜ao reconheceu que o desenvolvimento fora do controle do departamento de TI era um problema priorit´ario e decidiu adotar uma estrat´egia para lidar com o cen´ario. Foi inclu´ıda no Plano Diretor de Tecnologia uma iniciativa espec´ıfica para lidar com desenvolvimento de sistemas departamentais. A iniciativa era centrada em prover ferramenta e suporte para usu´arios desenvolvedores.
Foi tamb´em criada, dentro do departamento de TI, uma unidade espec´ıfica de governanc¸a e apoio ao desenvolvimento descentralizado. Ela visava garantir a qualidade, seguranc¸a e padronizac¸˜ao das aplicac¸˜oes desenvolvidas pelos diversos departamentos, oferecendo um novo modelo de desenvolvimento.
Para lidar com a rotatividade de funcion´arios e estagi´arios, o departamento de TI intensificou a adoc¸˜ao de padr˜oes e documentac¸˜ao. Em 2009, criou-se um n´ucleo de apoio ao desenvolvimento departamental cujo objetivo era reduzir o n´umero de diferentes tecnologias no cliente, padronizar ainda mais as aplicac¸˜oes desenvolvidas por usu´arios e apoiar a continuidade e qualidade das soluc¸˜oes departamentais existentes. Por exemplo, o departamento de TI definiu o uso de um documento ´unico, a Descric¸˜ao Geral da Aplicac¸˜ao, focada na vis˜ao e nos requisitos do sistema. Com um documento simples, esperava-se incentivar uma atualizac¸˜ao mais frequente. Em 2017, a organizac¸˜ao ainda enxerga a rotatividade de desenvolvedores um desafio.
Estruturas de tomada de decis˜ao. O departamento de TI define regras sobre como projetos devem ser conduzidos. Os sistemas s˜ao classificados quanto `a abordagem de provimento (centralizado ou descentralizado) e quanto `as caracter´ısticas da soluc¸˜ao (departamental ou corporativa). Projetos departamentais devem preferencialmente ser desenvolvidos no modelo descentralizado e projetos corporativos no modelo centralizado.
No entanto, projetos corporativos podem ser desenvolvidos de forma descentralizada. ´E necess´aria uma aprovac¸˜ao do comitˆe gestor de TI.
As ´areas de neg´ocio, em parceria com o departamento de TI, avaliam a necessidade, pertinˆencia e oportunidade do desenvolvimento da soluc¸˜ao. Al´em disso, a padronizac¸˜ao de processo de desenvolvimento descentralizado, infraestrutura e tecnologias para tal ´e exclusividade do departamento de TI. Cabe `as unidades de neg´ocio o poder de alterar os processos de trabalho que ser˜ao sistematizados pelo desenvolvimento.
Processos de alinhamento e Abordagens de comunicac¸˜ao Os riscos s˜ao gerenciados de maneira compartilhada. A ´area de neg´ocio lida com riscos gerais na conduc¸˜ao do projeto. J´a o departamento de TI ´e respons´avel por evoluir o modelo de desenvolvimento descentralizado (atrav´es do servic¸o de apoio criado), e lidar com riscos associados `a contratac¸˜ao de estagi´arios de TI e fornecimento de infraestrutura.
Um exemplo de risco identificado foi o de falhas na seguranc¸a de dados.
O departamento de TI determinou que aplicac¸˜oes com funcionalidade muito cr´ıticas deveriam passar por um conjunto de testes antes de entrar em produc¸˜ao. Essa definic¸˜ao ocorreu em conjunto com as ´areas de neg´ocio.
Ao longo dos anos de experiˆencia, o departamento de TI identificou a necessidade de criar algumas pol´ıticas para evitar riscos relacionados `a seguranc¸a, desempenho, manutenibilidade, confiabilidade e acur´acia das informac¸˜oes. Por exemplo, “usu´arios podem ter acesso `as bases de dados corporativos, mas n˜ao podem gravar”.
Outra pol´ıtica criada definiu que somente o departamento de TI poderia fornecer
´areas de trabalho para utilizac¸˜ao da ferramenta. Assim, a TI tem o controle das aplicac¸˜oes em desenvolvimento, com o objetivo de gerir e acompanhar com mais facilidade os usu´arios desenvolvedores. O departamento de TI monitora o ambiente acerca do consumo de recursos, como processamento e armazenamento, e para que boas pr´aticas sejam seguidas.
A Tabela 2 resume as estruturas de tomada de decis˜ao da organizac¸˜ao A, parte das quest˜oes gerenciais.
Tabela 2. Estruturas de tomada de decis ˜ao do Caso A
Dom´ınio Tomada de Decis˜ao
Alocac¸˜ao de orc¸amento
Federada
Gest˜ao de demanda Federada Priorizac¸˜ao de
projetos
Federada
Alocac¸˜ao de pessoas Federado (TI recruta e treina estagi´arios de TI/ ´Area de
neg´ocio contrata os estagi´arios e aloca funcion´arios de neg´ocio) Arquitetura Centralizada
Infraestrutura Centralizada
5.1.3. Fatores cr´ıticos de sucesso
Tecnologia. A ferramenta principal de desenvolvimento escolhida para o desenvolvimento descentralizado foi a Oracle Application Express (ORACLE, 2017), mais conhecida como Apex. Ao conhecer a agilidade e simplicidade do desenvolvimento que a ferramenta possibilitava, a alta direc¸˜ao resolveu adot´a-la, visto que o ´org˜ao j´a possu´ıa uma licenc¸a Oracle e a ferramenta Oracle Apex poderia ser utilizada sem custos adicionais.
Um dos entrevistados avalia a facilidade de uso da ferramenta:
”[...] excelente ferramenta para desenvolvimento r´apido de sistemas, com uma excelente curva de aprendizado e sem a exigˆencia de profissionais com conhecimentos avanc¸ados em TI para o desenvolvimento de sistemas de menor complexidade e de uso cotidiano. Conforme o profissional vai se especializando ainda mais no uso dessa ferramenta e tamb´em nas tecnologias que a rodeiam, ent˜ao sistemas mais robustos v˜ao sendo desenvolvidos, fruto de uma evoluc¸˜ao consider´avel das ´ultimas vers˜oes de Apex que foram lanc¸adas no mercado.”
No entanto, tamb´em identifica limitac¸˜oes:
“Nem toda unidade quer desenvolver seu sistema e a tecnologia Apex funciona apenas para sistemas web [...] dif´ıcil integrac¸˜ao com dispositivos de hardware”
Em 2017, a organizac¸˜ao ainda enxerga desafios relacionados `a estabilizac¸˜ao de sistemas desenvolvidos.
Treinamento. Para padronizar o desenvolvimento das aplicac¸˜oes, foram criados treinamentos para o Oracle Apex. O departamento de TI criou a infraestrutura necess´aria para hospedar o curso na Internet. Todos os usu´arios desenvolvedores passaram a realizar o treinamento antes de iniciar o desenvolvimento.
Suporte. Em 2009, foi criado um servic¸o de apoio ao EUD, que tinha o objetivo de gerenciar processos diversos do desenvolvimento descentralizado e apoiar os usu´arios desenvolvedores. Por exemplo, o grupo fornece o servic¸o de selec¸˜ao de estagi´arios de TI para apoiar o desenvolvimento das aplicac¸˜oes EUD, sendo que a decis˜ao ´e da ´area de neg´ocio. O grupo tamb´em facilitava a identificac¸˜ao de novos projetos com complexidade alta para o departamento de TI. Aos poucos, o grupo foi conseguindo estabelecer sua func¸˜ao consultiva, n˜ao se envolvendo efetivamente no desenvolvimento e manutenc¸˜ao de sistemas.
A Figura 2 sintetiza os resultados do Caso A, em relac¸˜ao ao elementos apresentados no framework conceitual, assim como suas interac¸˜oes. Como elemento novo, ressalta-se a TI Sombra. H´a tamb´em uma relac¸˜ao direta entre “Quest˜oes Gerenciais e Mecanismos de Governanc¸a”e “Treinamento, Suporte, Experts e Selec¸˜ao de Estagi´arios”, visto que o departamento de TI teve papel chave em priorizar recursos e estruturar tais ac¸˜oes. No framework conceitual inicial, esses dois elementos n˜ao estavam relacionados. O sombreamento em cinza ressalta o foco do departamento de TI, que tenta estabilizar priorizar os motivadores do usu´ario, enquanto garante parte do controle e governanc¸a.
5.2. Caso B
5.2.1. Motivadores do usu´ario
O desenvolvimento por usu´ario final iniciou em 2012, a partir da experiˆencia do caso A. A principal motivac¸˜ao para a adoc¸˜ao do modelo naquele momento era prover uma ferramenta aos usu´arios, alternativa ao uso de planilhas, para resolver as demandas das
´areas de neg´ocio. Um dos entrevistados comenta:
“No in´ıcio da adoc¸˜ao da metodologia os sistemas eram essencialmente departamentais, aqueles casos t´ıpicos de se sistematizar um pequeno controle geralmente feito em planilha.”
Os funcion´arios da ´area de neg´ocio usavam planilhas com grandes volumes de dados (planilhas de 250 colunas) para realizar suas atividades. A possibilidade de importar as planilhas em uma ferramenta de desenvolvimento r´apido, sem entrar na fila do departamento de TI era muito animadora. Al´em disso, seria poss´ıvel consultar o sistema central, onde os principais dados corporativos est˜ao. Por fim, poderiam atualizar os dados de maneira concorrente, o que antes era imposs´ıvel pelas planilhas.
Figura 2. S´ıntese do Caso A
Inicialmente, havia trˆes modalidades de desenvolvimento: desenvolvimento realizado por funcion´ario da organizac¸˜ao B, desenvolvimento realizado por estagi´ario alocado nas ´areas de neg´ocio e desenvolvimento por estagi´ario alocado na ´area de TI.
O grupo de usu´arios-desenvolvedores era composto por dois funcion´arios da ´area de neg´ocio e um estagi´ario de TI. Com o tempo, havia 8 estagi´arios que apoiavam diversos funcion´arios da ´area de neg´ocio no desenvolvimento de aplicac¸˜oes. Um dos entrevistados afirma:
”cada analista respons´avel pela soluc¸˜ao fica a cargo tanto da evoluc¸˜ao como da sustentac¸˜ao. Como as necessidades ultimamente aumentaram muito, n˜ao ´e poss´ıvel separar os pap´eis, e para cada sistema existe o funcion´ario respons´avel que acaba sendo o especialista naquele assunto.
[...] quando h´a estagi´ario alocado na ´area, geralmente a sustentac¸˜ao e evoluc¸˜ao s˜ao compartilhadas, ficando a gest˜ao negocial e demandas mais complexas com o servidor, e o restante para o estagi´ario”
Atualmente, 19 ´areas de neg´ocio desenvolvem software nesse modelo. H´a 10 funcion´arios do departamento de TI desenvolvendo soluc¸˜oes para 14 dessas ´areas. Nas demais, h´a 5 funcion´arios respons´aveis por sistemas, um em cada ´area. Essas 5 ´areas demandam novos sistemas e correc¸˜oes muito r´apidas, por isso o departamento de TI decidiu alocar seus funcion´arios diretamente na ´area negocial. Por falta de recursos, n˜ao h´a mais estagi´arios alocados nas ´areas de neg´ocio, apenas dentro da TI.
Um dos benef´ıcios percebidos do modelo foi a velocidade de entrega de soluc¸˜oes.
Era poss´ıvel ter um sistema pronto em 6 meses, o que deixava os envolvidos satisfeitos pela sensac¸˜ao de atingimento de meta em um prazo razo´avel. O departamento de TI considera que a tecnologia APEX ´e uma soluc¸˜ao que consegue atender a ´area fim do
´org˜ao, que vinha sendo pouco servida pela TI. Um dos entrevistados do departamento afirma:
”H´a muitos anos essas unidades vinham usando apenas o sistema processual da casa. A partir do momento que eles tiveram acesso a uma ferramenta que lhes deu certa independˆencia, rapidamente aderiram.
Antes disso, o departamento de TI nem conseguia atender esse tipo de demanda”
Desde 2012, 38 sistemas foram desenvolvidos nesse modelo e encontram-se em manutenc¸˜ao.
5.2.2. Quest˜oes Gerenciais e Contextuais
A partir da experiˆencia do caso A, a organizac¸˜ao B considerou que a gratuidade da licenc¸a da ferramenta Oracle/APEX, junto `a baixa curva de aprendizagem, eram uma vantagem importante relacionada `a custo-efic´acia de iniciativa. No entanto, a organizac¸˜ao n˜ao formalizou o desenvolvimento descentralizado. No Plano Diretor de TI h´a menc¸˜oes sobre iniciativas em Apex, principal ferramenta adotada na abordagem descentralizada, mas n˜ao descreve um processo de desenvolvimento para esse modelo.
Estruturas de tomada de decis˜ao. O departamento de TI define regras sobre como projetos devem ser conduzidos. Todas as demandas de desenvolvimento de software do ´Org˜ao P´ublico B s˜ao captadas e priorizadas de forma centralizada por equipes de an´alise t´ecnica. A partir desse processo a demanda pode seguir por trˆes caminhos: ser desenvolvida de forma centralizada pela TI tradicional, ser desenvolvida por funcion´arios de TI alocados na ´area de neg´ocio na ferramenta APEX, ou ainda ser desenvolvida pelo departamento de TI (funcion´ario ou estagi´ario), utilizando APEX.
Os crit´erios para definir se uma demanda ser´a desenvolvida no modelo EUD ou na TI centralizada levam em considerac¸˜ao fatores como a expectativa de tempo para atendimento da demanda, a complexidade da soluc¸˜ao, a plataforma em que ser´a utilizada a soluc¸˜ao e a possibilidade da necessidade ser atendida por um software de mercado. ´E avaliado, de maneira informal, se a necessidade do usu´ario demandante ser´a plenamente atendida com um sistema Apex, j´a considerando sua expectativa final da soluc¸˜ao.
No in´ıcio da metodologia de desenvolvimento descentralizado no ´Org˜ao P´ublico B, as demandas eram essencialmente departamentais de casos simples para sistematizac¸˜ao um controle geralmente feito em planilhas. Com o tempo, as necessidades foram ficando mais complexas, necessitando de um acompanhamento mais pr´oximo dos funcion´arios da TI. Atualmente, a tecnologia utilizada nesta metodologia, o Apex, tornou-se uma opc¸˜ao de tecnologia de sistemas assim como outras do desenvolvimento centralizado como Java e PHP. Um entrevistado afirma:
“Com o tempo, as necessidades foram ficando mais complexas, com muitas integrac¸˜oes, necessitando cada vez mais de um acompanhamento mais dedicado dos servidores que gerenciavam os estagi´arios.
Atualmente, tornou-se uma opc¸˜ao de tecnologia de sistema da forma como s˜ao tratados Java e PHP aqui, ou seja, essa equipe de 10 servidores
´e respons´avel por sistemas que s˜ao sens´ıveis para o ´org˜ao [...] na grande maioria dos casos, sistemas nacionais”
Um dos entrevistados comenta sobre a dificuldade de se estabelecer, de fato, o desenvolvimento por usu´ario final:
“N˜ao d´a pra ficar com o ’end-user’ porque nem o que ´e mais centralizado, no estilo RAD, a gest˜ao ´e madura”
E poss´ıvel, no entanto, que alguns desenvolvimentos sejam iniciados na ´area´ de neg´ocio, sem passar pelo processo de captac¸˜ao e an´alise centralizada, conhecido como TI Sombra. Nesses casos, o departamento de TI tomar´a conhecimento do sistema no momento em que for solicitada sua implantac¸˜ao em produc¸˜ao, uma vez que os usu´arios-desenvolvedores n˜ao possuem permiss˜ao para este procedimento.
O departamento de TI gerencia toda a infraestrutura necess´aria para o uso da ferramenta Apex, incluindo as necessidades relacionadas `a administrac¸˜ao dos dados.
Sobre a gest˜ao dos dados, um dos entrevistados comenta:
“Nossa equipe de administrac¸˜ao de dados mant´em o controle da criac¸˜ao de novas tabelas e demais objetos de banco, e recomenda que utilizemos dados e tabelas de esquemas corporativos sempre que poss´ıvel [...] nem me lembro que tenha ocorrido de um sistema Apex solicitar alterac¸˜oes em modelos corporativos. Em geral, o esquema espec´ıfico do sistema Apex fica com os dados t´ıpicos daquela necessidade, e os demais dados j´a existentes em outras bases s˜ao apenas consultados ou recuperados, sem redundˆancia”
N˜ao identificou-se um processo espec´ıfico de monitoramento de uso da infraestrutura por esses sistemas. Um dos entrevistados narrou um caso de falha grave de uma aplicac¸˜ao desenvolvida nessa abordagem:
“Um select do mal derrubou o banco e todos os sistemas conectados ao banco de dados”
Processos de alinhamento. O departamento iniciou uma wiki com o processo para orientar os desenvolvedores que utilizam Apex. No entanto, esse site tornou-se desatualizado, conforme declarou um dos entrevistados:
“O que temos de formalizac¸˜ao ´e a p´agina da Wiki onde foi inicialmente detalhado o processo, mas que j´a n˜ao conta com atualizac¸˜ao constante”
Abordagem de comunicac¸˜ao.O ´unico canal oficial de comunicac¸˜ao identificado acerca da iniciativa de descentralizac¸˜ao foo o Plano Diretor. No entanto, sem detalhamento ou outras comunicac¸˜oes de reforc¸o, conforme menciona o entrevistado:
“No Plano Diretor h´a o detalhamento das iniciativas em Apex para o per´ıodo, mas n˜ao h´a uma descric¸˜ao do processo de desenvolvimento.
Tamb´em n˜ao h´a nenhuma publicac¸˜ao em pol´ıtica ou portaria.”
A Tabela 3 resume as estruturas de tomada de decis˜ao da organizac¸˜ao B, parte das quest˜oes gerenciais.
Tabela 3. Estruturas de tomada de decis ˜ao do Caso B
Dom´ınio Tomada de Decis˜ao
Alocac¸˜ao de orc¸amento
Centralizada
Gest˜ao de demanda Centralizada Priorizac¸˜ao de
projetos
Federada
Alocac¸˜ao de pessoas Centralizada (Funcion´arios e Estagi´arios de TI)
Arquitetura Centralizada Infraestrutura Centralizada
5.2.3. Fatores cr´ıticos de sucesso
Tecnologia.De acordo com os entrevistados, a ferramenta proporciona uma curva r´apida de aprendizado e seguranc¸a. No entanto, um dos entrevistados comenta sobre dificuldades em relac¸˜ao `a seguranc¸a da informac¸˜ao no uso da ferramenta selecionada (Apex):
“na vers˜ao 5 da ferramenta h´a bloqueio a alguns tipos de ataque que derrubavam o Apex na vers˜ao anterior como SQL injection”
Para muitos entrevistados, a ferramenta pode n˜ao parecer t˜ao amig´avel para o usu´ario sem conhecimento de tecnologia. Al´em disso, `a medida que as interfaces se tornam mais complexas, o desenvolvimento torna-se mais lento. Outra limitac¸˜ao mencionada por um dos entrevistados:
“os relat´orios nem sempre ficam bom no Apex, nestes casos optamos por outras ferramentas especializadas”
Al´em do Apex, a organizac¸˜ao B permite desenvolver em outras tecnologias. No entanto, ´e necess´ario que a ´area interessada obtenha uma autorizac¸˜ao, a qual poder´a ser emitida ap´os a avaliac¸˜ao da tecnologia pela TI.
Treinamento. Para que estagi´arios da TI ou funcion´arios passem a utilizar o Apex, eles passam por um treinamento de duas semanas, realizado pela TI. Ao final desta capacitac¸˜ao, eles est˜ao aptos a construir sistemas que fazer as operac¸˜oes b´asicas de inclus˜ao, exclus˜ao e alterac¸˜ao de registros em tabelas do banco de dados.
Cultura Durante as entrevistas sobre perspectivas futuras, os entrevistados consideram importante realizarem uma esp´ecie de campanha de incentivo para sensibilizar e motivar os funcion´arios para EUD. Apontaram que n˜ao h´a ainda uma motivac¸˜ao intr´ınseca dos funcion´arios para se engajarem neste modelo, al´em da necessidade de reconhecimento pelo trabalho.
A Figura 3 sintetiza os resultados do Caso B, em relac¸˜ao ao elementos apresentados no framework conceitual, assim como suas interac¸˜oes. Como elemento novo, ressalta-se a TI Sombra, tamb´em resultado do Caso A. H´a tamb´em uma relac¸˜ao direta entre “Quest˜oes Gerenciais e Mecanismos de Governanc¸a”e “Treinamento,
Suporte, Experts e Selec¸˜ao de Estagi´arios”, visto que o departamento de TI n˜ao priorizou recursos para estruturar tais ac¸˜oes. Assim, n˜ao houve condic¸˜oes para sustentac¸˜ao da iniciativa de descentralizac¸˜ao. A tecnologia adotada (Apex) passou a ser utilizada para desenvolvimento r´apido de aplicac¸˜oes, ou Rapid Application Development (RAD). O sombreamento em cinza ressalta o foco do departamento de TI, que tenta estabilizar suas pr´oprias quest˜oes gerenciais antes de priorizar os motivadores do usu´ario.
Figura 3. S´ıntese do Caso B
6. Discuss˜ao e Limitac¸˜oes
Em ambos os casos, como grande patrocinador do investimento, os departamentos de TI priorizam a otimizac¸˜ao do modelo para favorecer seu pr´oprio custo-efic´acia, dado que antes n˜ao atendiam (ou atendia pobremente) muitas das ´areas de neg´ocio beneficiadas.
No caso A, a organizac¸˜ao foi bem-sucedida em articular alguns dos fatores consideramos como cr´ıticos de sucesso para adoc¸˜ao de EUD [Fischer et al. 2004], o que permitiu avanc¸ar mais na descentralizac¸˜ao da func¸˜ao de TI do que no caso B.
A organizac¸˜ao A priorizou e fez investimentos ao longo de 10 anos para assegurar treinamento e suporte ao desenvolvimento por usu´ario final, al´em de estabelecer claramente pelo menos dois mecanismos de governanc¸a: estruturas de tomada de decis˜ao e abordagens de comunicac¸˜ao.
No caso B, os funcion´arios n˜ao consideram a gest˜ao da TI centralizada madura suficiente, tornando-se um passo dif´ıcil estruturar um maior n´ıvel de descentralizac¸˜ao.
O modelo, inicialmente pensado para o usu´ario desenvolvedor, acabou sendo adaptado para uso do pr´oprio departamento de TI, que passou a desenvolver soluc¸˜oes r´apidas com a ferramenta selecionada (Apex) para ´areas de neg´ocio. Com o passar do tempo, o modelo tornou-se uma alternativa para o desenvolvimento centralizado, sem necessidade de times grandes ou terceirizac¸˜ao. Assim, o departamento de TI do caso B atende mais
departamentos do que antes, por´em sem empoderar o usu´ario das ´areas de neg´ocio, o que limita o alcance do que pode ser feito atrav´es da tecnologia.
O resultado sugere que a organizac¸˜ao primeiro precisa aprender a gerir prioridades e demandas de TI de maneira centralizada, para que seja poss´ıvel discernir o quˆe e como descentralizar func¸˜oes de TI para outros departamentos e pessoas. Tamb´em sugere que a abordagem EUD pode acabar tornando-se um RAD quando as quest˜oes gerenciais e mecanismos de governanc¸a n˜ao est˜ao suficientemente maduros para dar suporte `a adoc¸˜ao da tecnologia pelo usu´ario final. A ferramenta de apoio ao desenvolvimento por usu´ario final passa a ser usada pelo pr´oprio departamento de tecnologia para o desenvolvimento r´apido de aplicac¸˜oes (RAD). Assim, uma iniciativa EUD pode acabar sendo distorcida ou transformar-se em mais uma forma de desenvolvimento centralizado, agora apoiado por ferramentas originalmente voltadas para usu´arios finais.
N˜ao houve evidˆencias no caso B de que h´a motivadores suficientes para gerar condic¸˜ao de aprendizado para usu´arios aprenderem novas tecnologias providas pela organizac¸˜ao. Os dados apontam que a organizac¸˜ao falhou em criar condic¸˜oes para essa motivac¸˜ao em maior escala. Em ambos os casos, houve participac¸˜ao ativa de funcion´arios e estagi´arios com conhecimento pr´evio em TI. N˜ao houve evidˆencia de que pessoas sem esse conhecimento anterior se interessassem por aprender a tecnologia para desenvolver sistemas.
Os riscos de seguranc¸a, a complexidade de algumas demandas em termos de n´umero de integrac¸˜oes, assim como a otimizac¸˜ao do modelo para custo-eficiˆencia para o departamento de TI s˜ao forc¸as centralizadoras. Em ambos os casos, a seguranc¸a foi um dos fatores importantes para maior centralizac¸˜ao do modelo, confirmando estudos anteriores sobre EUD e TI Sombra [Panko and Port 2013]. Mesmo as melhorias relacionadas a ataques por injec¸˜ao pela nova vers˜ao da ferramenta Apex, usada em ambas organizac¸˜oes, n˜ao modificaram a vis˜ao das organizac¸˜oes sobre esse grau de centralizac¸˜ao.
De fato, estudos apontam que, em geral, organizac¸˜oes falham em enderec¸ar a vis˜ao do usu´ario sobre seguranc¸a, assim como seu comportamento e conhecimento b´asico em como prevenir problemas com dados sens´ıveis [Gross and Rosson 2007]. H´a limitac¸˜oes de usabilidade nas pr´oprias ferramentas oferecidas aos usu´arios, que induzem a erros e falhas subsequentes. Al´em disso, o usu´ario final pode lidar com quest˜oes b´asicas de seguranc¸a quando h´a treinamento, conscientizac¸˜ao, monitoramento e motivac¸˜ao [Stanton et al. 2005].
Ambas organizac¸˜oes adotaram a mesma tecnologia, considerada adequada para EUD em termos de curva de aprendizado e possibilidades de integrac¸˜ao. No entanto, a ferramenta ainda assim requer treinamento e, em ambas organizac¸˜oes, o usu´ario desenvolvedor, em geral, tem conhecimento pr´evio de TI. A ferramenta Apex foi avaliada quanto a 11 caracter´ısticas favor´aveis ao EUD [Melo et al. 2017]. Os resultados demonstram que a ferramenta tem limitac¸˜oes de usabilidade, em particular, acessibilidade, localizac¸˜ao para portuguˆes, flexibilidade e competˆencias necess´arias para manipulac¸˜ao. Al´em disso, a ferramenta ´e voltada para um dom´ınio espec´ıfico de aplicac¸˜oes que consultam e atualizam dados armazenados em bancos de dados relacionais [Richardson and Rymer 2016].
Os resultados indicam que em ambos os casos ainda ocorre TI sombra. Esse
resultado confirma estudos que afirmam que sistemas sombra persistem ou retornam, ainda que haja esforc¸os para sua eliminac¸˜ao [Walters 2013, F¨urstenau et al. 2017]. No caso A, mesmo com investimento de 10 anos no aprimoramento da descentralizac¸˜ao, ainda h´a espac¸o para investigac¸˜ao dos motivadores de usu´ario que levam `a adoc¸˜ao de outros processos e tecnologias para construc¸˜ao de soluc¸˜oes.
A situac¸˜ao pode ter sido originada de um conflito entre a gest˜ao e as motivac¸˜oes dos usu´arios, que gostariam de maior empoderamento, como tamb´em por umtrade-off relacionado ao custo de aprendizado, programac¸˜ao e depurac¸˜ao da ferramenta pelo usu´ario. No entanto, apenas futuros estudos poder˜ao confirmar essas hip´oteses.
Importante ressaltar que a TI sombra tamb´em ´e vista como fonte de inovac¸˜ao em muitas organizac¸˜oes [Gy¨ory et al. 2012], n˜ao sendo necessariamente um problema a ser eliminado, mas um fenˆomeno a ser compreendido, principalmente pelo potencial de aumento de produtividade, flexibilidade e inovac¸˜ao dirigida por usu´ario [Silic and Back 2014, Zimmermann et al. 2017].
Nesse contexto, ´e importante notar que n˜ao houve menc¸˜ao nas entrevistas, no question´ario ou nos documentos analisados sobre qualquer perspectiva de inovac¸˜ao por tr´as das iniciativas de descentralizac¸˜ao por EUD, como sugere a literatura da
´area [Niehaves et al. 2012, K¨offer et al. 2014, Andriole 2015, Bygstad 2016]. Embora algumas organizac¸˜oes j´a invistam na criac¸˜ao de infraestruturas que empoderem o usu´ario desenvolvedor dentro e fora da organizac¸˜ao [Angeli et al. 2014, Bygstad 2016], os casos estudados n˜ao demonstram essa vis˜ao da func¸˜ao de TI. H´a infraestrutura dispon´ıvel, mas n˜ao prevˆe suporte a uma gama ampla e heterogˆenea de aplicac¸˜oes desenvolvidas pelo usu´ario desenvolvedor, de modo a garantir flexibilidade e empoderamento.
Al´em disso, em ambos os casos n˜ao foi identificado um monitoramento do valor gerado pela abordagem al´em da maior vaz˜ao de sistemas sob mecanismos de reduc¸˜ao de riscos. Assim, pode n˜ao haver ainda um motivo claro para avanc¸ar na descentralizac¸˜ao da TI por EUD, potencialmente atingindo modelos de governanc¸a descentralizados ou participat´orios.
Este estudo possui ameac¸as `a validade inerentes a estudos de caso: validade de construto, interna, externa e confiabilidade [Yin 2009]. Em relac¸˜ao `a validade de construto, triangulou-se trˆes tipos de fontes de evidˆencia, al´em de discuss˜oes entre o time de pesquisa. Em relac¸˜ao `a validade interna, procurou-se estabelecer relac¸˜oes causais atrav´es de correspondˆencia de padr˜oes entre o framework conceitual proposto e os padr˜oes observados nos dados. As relac¸˜oes n˜ao observadas n˜ao foram descritas nos resultados (Figuras 2 e 3), assim como elementos e relac¸˜oes novos foram adicionados de forma destacada. Para aumentar a validade externa dos resultados, estudamos duas organizac¸˜oes com razo´avel similaridade de intenc¸˜oes para que fosse poss´ıvel contrastar resultados. Por fim, o instrumento de coleta de dados ´e apresentado de forma a aumentar a confibilidade do procedimento adotado.
A principal limitac¸˜ao do estudo foi baixa quantidade de dados provenientes de usu´arios-finais desenvolvedores n˜ao participantes das iniciativas oficiais de descentralizac¸˜ao. Essa perspectiva certamente enriqueceria a compreens˜ao do sistema socio-t´ecnico estudado, assim como circunstˆancias que levam `a existˆencia de TI sombra.
7. Conclus˜ao
A maior parte do software j´a ´e escrito por usu´arios finais que precisam cumprir objetivos de neg´ocio atrav´es da TI, embora a governanc¸a estabelecida pelas organizac¸˜oes nem sempre seja adequada. A compreens˜ao de como organizar a descentralizac¸˜ao da func¸˜ao de TI para usu´arios finais, de modo a preparar a organizac¸˜ao para os desafios e oportunidades do s´eculo 21, torna-se chave.
Nesta pesquisa apresentou-se dois estudos de caso em organizac¸˜oes que buscavam descentralizar a func¸˜ao de TI atrav´es de EUD. Dentre os resultados analisados por meio do framework conceitual proposto, destaca-se que a maturidade pr´evia em governanc¸a da TI foi fator importante na capacidade de descentralizac¸˜ao atrav´es de EUD, embora ambos casos n˜ao tenham atingido alto grau de descentralizac¸˜ao. Al´em disso, a TI sombra permaneceu em ambos os casos. Ambas organizac¸˜oes n˜ao demonstraram buscar inovac¸˜ao com as iniciativas de descentralizac¸˜ao, embora essa seja uma vis˜ao fundamental da func¸˜ao de TI no s´eculo 21.
No contexto de governanc¸a de TI em plena economia digital, expandir a investigac¸˜ao sobre a dinˆamica das tens˜oes de poder entre o departamento de TI e os usu´arios finais desenvolvedores ´e uma quest˜ao relevante, dado que a TI vem tornando-se cada vez mais pervasiva e de f´acil acesso aos usu´arios [F¨urstenau et al. 2017].
Como trabalho futuro, existem diversas avenidas poss´ıveis de pesquisa. Estudar mais organizac¸˜oes buscando compreender a descentralizac¸˜ao e empoderamento de usu´arios.
Outro caminho interessante ´e aprofundar a compreens˜ao das jornadas de aprendizado e trabalho do usu´ario-final desenvolvedor para compreender os caminhos entre EUD e TI Sombra. Compreender a interac¸˜ao de usu´arios e tecnologias de suporte a EUD
´e de extrema relevˆancia, j´a que elas podem viabilizar a entrada de mais usu´arios desenvolvedores. Por fim, uma linha interessante de investigac¸˜ao ´e mapear e investigar que infraestruturas de governanc¸a participat´oria vˆem sendo propostas, uma vez que elas podem viabilizar o controle (automatizado) sem sacrificar o empoderamento de usu´arios e at´e mesmo possibilitar o envolvimento ativo destakeholdersexternos `a organizac¸˜ao.
Referˆencias
Andriole, S. J. (2015). Who owns IT? Communications of the ACM, 58(3):50–57.
Angeli, A. D., Bordin, S., and Blanco, M. M. (2014). Infrastructuring participatory development in information technology. InParticipatory Design Conference, PDC’14, Windhoek, Namibia, October 6-10, 2014, Volume 1 - Research Papers, pages 11–20.
Barker, S. and Fiedler, B. (2011). Developers, decision makers, strategists or just end-users? redefining end-user computing for the 21st century: A case study. Journal of Organizational and End User Computing, 23(2):1–14.
Benbasat, I., Goldstein, D. K., and Mead, M. (1987). The case research strategy in studies of information systems. MIS Quarterly, 11(3):369–386.
Bharadwaj, A., Sawy, O. A. E., Pavlou, P. A., and Venkatraman, N. (2013). Visions and voices on emerging challenges in digital business strategy. MIS Quarterly, 37(2):633–661.
Bradley, R. V., Byrd, T. A., Pridmore, J. L., Thrasher, E., Pratt, R. M., and Mbarika, V. W.
(2012). An empirical examination of antecedents and consequences of IT governance in us hospitals. Journal of Information Technology, 27(2):156–177.
Bygstad, B. (2016). Generative innovation: a comparison of lightweight and heavyweight IT. Journal of Information Technology, 32(2):180–193.
Chua, C., Storey, V., and Chen, L. (2014). Central IT or shadow IT? factors shaping users’ decision to go rogue with IT. In Myers, M. D. and Straub, D. W., editors,ICIS.
Association for Information Systems.
DeLone, W., Migliorati, D., and Vaia, G. (2017).Digital IT Governance, pages 205–230.
Springer International Publishing, Cham.
Dittrich, Y., Bolmsten, J., and Eriksson, J. (2017). End User Development and Infrastructuring – Sustaining Organizational Innovation Capabilities, pages 165–206.
Springer International Publishing, Cham.
Ferneley, E. (2007). Covert end user development: A study of success. Journal of Organizational and End User Computing, 19(1):62–71.
Figueiredo, R. M. d. C., Venson, E., Melo, C. d. O., Ramalho, C., Modesto, A. S., Melo, L. S. d., Nobre, A. J., Moraes, J. M., Ferreira, M. H. P., and Martins, P. (2017).
Desenvolvimento pelo usu´ario final: conceitos, estrat´egias e casos de adoc¸˜ao: relat´orio de pesquisa. Technical report, Universidade de Bras´ılia.
Fischer, G. (2009). End-user development and meta-design: Foundations for cultures of participation. InEnd-User Development, 2nd International Symposium, IS-EUD 2009, Siegen, Germany, March 2-4, 2009. Proceedings, pages 3–14.
Fischer, G., Giaccardi, E., Ye, Y., Sutcliffe, A. G., and Mehandjiev, N. (2004).
Meta-Design: A Manifesto for End-User Development. Communications of the ACM, 47(9):33.
Frey, T. and Buxmann, P. (2011). The importance of governance structures in IT project portfolio management. In 19th European Conference on Information Systems, ECIS 2011, Helsinki, Finland, June 9-11, 2011, page 17.
F¨urstenau, D., Rothe, H., and Sandner, M. (2017). Shadow systems, risk, and shifting power relations in organizations. Communications of the Association for Information Systems (CAIS), 41:3.
Gross, J. B. and Rosson, M. B. (2007). Looking for trouble: Understanding end-user security management. In Proceedings of the 2007 Symposium on Computer Human Interaction for the Management of Information Technology, CHIMIT ’07, New York, NY, USA. ACM.
Gy¨ory, A., Cleven, A., Uebernickel, F., and Brenner, W. (2012). Exploring the shadows:
IT governance approaches to user-driven innovation. In20th European Conference on Information Systems, ECIS 2012, Barcelona,Spain, June 10-13, 2012, page 222.
Haes, S. D. and Grembergen, W. V. (2009). An exploratory study into IT governance implementations and its impact on business/IT alignment. Information Systems Management, 26(2):123–137.
Karimi, J., Bhattacherjee, A., Gupta, Y. P., and Somers, T. M. (2000). The effects of mis steering committees on information technology management sophistication. Journal of Management Information Systems, 17(2):207–230.
Ko, A. J., Abraham, R., Beckwith, L., Blackwell, A., Burnett, M., Erwig, M., Scaffidi, C., Lawrance, J., Lieberman, H., Myers, B., Rosson, M. B., Rothermel, G., Shaw, M., and Wiedenbeck, S. (2011). The state of the art in end-user software engineering. ACM Computing Surveys (CSUR), 43(3):21:1–21:44.
K¨offer, S., Fielt, E., and Niehaves, B. (2015). IT consumerization and its effects on IT business value, IT capabilities, and the IT function. In19th Pacific Asia Conference on Information Systems, PACIS 2015, Singapore, July 5-9, 2015, page 169.
K¨offer, S., Ortbach, K., and Niehaves, B. (2014). Exploring the relationship between IT consumerization and job performance: A theoretical framework for future research.
CAIS, 35:14.
Lieberman, H., Patern`o, F., Klann, M., and Volker, W. (2006). End-User Development:
An Emerging Paradigm. Springer Netherlands, 1st edition.
Maceli, M. G. (2017). Tools of the Trade: A Survey of Technologies in End-User Development Literature, pages 49–65. Springer International Publishing, Cham.
Melo, C., Moraes, J., Ferreira, M., and da Costa Figueiredo, R. M. (2017). A method for evaluating end-user development technologies. In 23rd Americas Conference on Information Systems, AMCIS 2017, Boston, MA, USA, August 10-12, 2017.
Niehaves, B., K¨offer, S., and Ortbach, K. (2012). IT consumerization - A theory and practice review. In 18th Americas Conference on Information Systems, AMCIS 2012, Seattle, Washington August 9-11, 2012.
Panko, R. R. and Port, D. N. (2013). End user computing: The dark matter and dark energy of corporate IT. J. Organ. End User Comput., 25(3):1–19.
Peterson, R. (2004). Crafting information technology governance. EDPACS, 32(6):1–24.
Ping-Ju Wu, S., Straub, D. W., and Liang, T.-P. (2015). How information technology governance mechanisms and strategic alignment influence organizational performance:
insights from a matched survey of business and it managers.MIS Quarterly, 39(2):497 – A7.
Richardson, C. and Rymer, J. R. (2016). The Forrester Wave: Low-Code Development Platforms.
Silic, M. and Back, A. (2014). Shadow IT - a view from behind the curtain. Computers
& Security, 45:274–283.
Stanton, J. M., Stam, K. R., Mastrangelo, P., and Jolton, J. (2005). Analysis of end user security behaviors. Computers & Security, 24(2):124–133.
Trochim, W. M. (1989). Outcome pattern matching and program theory. Evaluation and Program Planning, 12(4):355 – 366. Special Issue: The Theory-Driven Perspective.
von Hippel, E. (2005). Democratizing Innovation. MIT Press.
Voss, C., Tsikriktsis, N., and Frohlich, M. (2002). Case research in operations management. International Journal of Operations & Production Management, 22(2):195–219.
Walters, R. (2013). Bringing IT out of the shadows. Network Security, 2013(4):5–11.
Weill, P. and Ross, J. (2004). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business School Press, Boston, MA, USA.
Weill, P. and Ross, J. (2005). A matrixed approach to designing IT governance. 46:26–34.
Winkler, T. J. and Brown, C. V. (2013). Horizontal allocation of decision rights for on-premise applications and software-as-a-service. Journal of Management Information Systems, 30(3):13–48.
Yin, R. K. (2009). Case Study Research: Design and Methods. Applied Social Research Methods. SAGE Publications.
Zimmermann, S., Rentrop, C., and Felden, C. (2014). Managing shadow IT instances - A method to control autonomous IT solutions in the business departments. In20th Americas Conference on Information Systems, AMCIS 2014, Savannah, Georgia, USA, August 7-9, 2014.
Zimmermann, S., Rentrop, C., and Felden, C. (2016). Governing identified shadow IT by allocating IT task responsibilities. In 22nd Americas Conference on Information Systems, AMCIS 2016, San Diego, CA, USA, August 11-14, 2016.
Zimmermann, S., Rentrop, C., and Felden, C. (2017). A multiple case study on the nature and management of shadow information technology. Journal of Information Systems, 31(1):79–101.
Apêndice A - Protocolo de Entrevista
Explicações gerais sobre o objetivo da entrevista:
<explicação dos objetivos - atentar para não enviesar
Explicar como estamos definindo EUD e Desenvolvimento descentralizado>
Permissão para gravação:
Antes de começar a entrevista, você tem alguma pergunta?
Roteiro de Entrevista Notas de pesquisa (observações
durante a entrevista) Entrevistador(a):
Data da entrevista:
Dados demográficos Entrevistado(a):
Organização:
Número de funcionários:
Indústria: Governo/_____
Área/Departamento:
Número de funcionários da área/depto:
Papel/Cargo:
Formação:
Experiência profissional:
Visão geral de EUD na Organização/Departamento 1. Qual foi a motivação para a adoção de EUD?
2. Quais áreas usam ferramentas EUD? Que
necessidades/problemas elas têm para o uso de EUD (ex:
automatizar operação, analisar dados, gerar relatório)?
Qual o critério para escolher o desenvolvimento descentralizado?
3. Que ferramentas são usadas? Qual o modelo de contratação (ex: assinatura, licença, software livre)?
4. Houve algum tipo de capacitação/treinamento para usar essas ferramentas? E outros tipos de investimento?
5. Como é o apoio da organização/departamento para esse tipo de atividade? (aguardar resposta e explorar cenários onde há reconhecimento ou problemas)
6. O que melhorou na organização com a adoção dessa abordagem? Quais as evidências?
7. Os objetivos iniciais foram alcançados? Você poderia contar um cenário onde isso ocorreu? ( explorar caso de sucesso, motivador de venda para outros adotarem) 8. Você poderia contar um cenário onde EUD não deu certo? (explorar caso de dor e muito aprendizado)
<Fechamento da entrevista>
