Apakah mungkin untuk mengambil pendekatan gesit fleksibel untuk proyek-proyek yang membutuhkan perkiraan waktu yang dihabiskan dan waktu yang dihemat?

25

Sebagai seseorang yang bekerja secara efektif dengan Agile sebelumnya, saya berusaha meyakinkan majikan saya tentang manfaatnya. Namun, manajemen bersikeras bahwa kami mempertahankan kemampuan untuk membuat perkiraan dimuka untuk menilai nilai bisnis proyek.

Sebagian besar pelanggan saya internal, dan saya baru-baru ini ditugaskan untuk berkeliling tim dan meminta mereka ide-ide tentang proses bisnis untuk diotomatisasi. Saya kemudian mencari tahu berapa banyak waktu yang dihabiskan untuk mereka, mencari tahu berapa banyak waktu solusi akan menghemat dan memperkirakan total waktu pengembangan. Dengan begitu, manajer dapat mencoba mengukur seberapa efektif suatu solusi dalam hal menghemat waktu.

Namun, bagi saya sepertinya tidak ada cara untuk mendekati persyaratan ini dengan cara "Agile". Persyaratan fleksibel berarti bahwa estimasi waktu yang diambil tidak hanya salah, tetapi juga estimasi potensi waktu yang dihemat. Saya menjelaskan sebanyak itu, menjelaskan mengapa itu mungkin bermasalah, tetapi diberi tahu itu tidak bisa dinegosiasikan.

Pertanyaan Bagaimana menjual pengembangan Agile ke (air terjun) klien memiliki beberapa saran yang berguna tentang cara "menjual" Agile ke pelanggan eksternal. Saya tidak mencoba menjualnya kepada klien eksternal: Saya mencoba mencari tahu bagaimana cara terbaik untuk mendamaikan tuntutan manajemen internal sambil mempertahankan metodologi yang saya yakin berfungsi dengan baik.

Apakah ada cara untuk mendekati tugas ini dengan cara yang fleksibel yang memungkinkan saya untuk mempertahankan setidaknya beberapa manfaat Agile?

agile Bob Tway
sumber
1
Jika memungkinkan, cobalah untuk menguraikan proyek menjadi bagian-bagian yang lebih kecil dan melihat apakah ada di antara mereka yang akan berguna sendiri, dengan bagian yang tersisa membangunnya. Manfaat untuk akurasi estimasi dari menyusutkan kerucut ketidakpastian Anda ( whatis.techtarget.com/definition/cone-of-uncertainty ) akan lebih besar daripada biaya fleksibilitas.
Ben Aaronson
1
Apakah Anda saat ini dapat membuat perkiraan yang akurat tentang berapa lama waktu yang dibutuhkan untuk suatu proyek?
Daenyth
2
@MattThrower ProTip: jika manajemen mempercayakan fungsi-fungsi TI penting kepada satu pengembang, maka mereka tidak pernah memiliki banyak kepercayaan atau kepercayaan pada TI untuk memulainya. Mereka tampaknya tidak yakin bahwa TI memiliki ROI yang baik atau mereka tidak akan terlalu ketat pada dompet.
maple_shaft
2
Jika Anda tidak dapat meyakinkan manajemen bahwa apa yang akan Anda lakukan akan menghemat lebih banyak uang daripada biaya untuk mengimplementasikannya, mengapa mereka membayar Anda untuk melakukannya? Agile adalah metodologi pengembangan, bukan metodologi proyek. Masalah Anda adalah meyakinkan orang lain bahwa perkiraan Anda akan sesuai dengan yang sebenarnya. Ketika Anda melakukan itu, mereka tidak peduli apa metodologi Anda. Setiap kali persyaratan berubah, Anda harus dapat mengatakan apa dampak perubahan itu dalam waktu atau upaya (dan karenanya biaya), jika tidak, bagaimana mereka akan tahu apakah perubahan itu sepadan atau tidak?
RobG
1
kemungkinan rangkap dari Cara menjual Agile development kepada klien (air terjun)
agas

Jawaban:

25

Seperti jawaban lain telah menyatakan, Manajemen memiliki hak untuk mendapatkan estimasi tingkat tinggi di muka suatu proyek. Mereka tidak masuk akal untuk mencoba menentukan ROI.

Salah satu pendekatan yang saya suka tentang Agile adalah bahwa ruang lingkup proyek tidak tetap. Awalnya dapat diukur pada tingkat Fitur dan Epik, kemudian bisnis dapat menentukan ROI berdasarkan fitur apa yang paling penting. Mungkin UI mewah dengan lonceng dan peluit memiliki nilai bisnis yang rendah, tetapi mesin alur kerja untuk menangani klaim memiliki ROI yang tinggi.

Ketika Anda menggabungkan seluruh proyek bersama-sama maka lebih sulit untuk memenuhi ROI daripada jika Anda fokus pada fungsionalitas bisnis penting yang diinginkan.

Inilah cara yang telah saya lakukan ini:

Ambil tonggak WBS Anda dan ubah masing-masing menjadi fitur yang bisa dikirim

Ini memungkinkan Anda untuk mengkategorikan proyek Anda menjadi sub-proyek mini yang memiliki nilai bisnis yang beragam. Masing-masing harus berdiri sendiri dalam hal nilai bisnis.

Ukuran T-Shirt Usaha pada Fitur

Ini adalah cara yang sangat mudah untuk mendapatkan gambaran kasar tentang seberapa besar atau melibatkan fitur tertentu. Mungkin fitur bernilai rendah masih memiliki ROI yang bagus jika mereka terlihat seperti kemenangan mudah.

Hancurkan Fitur menjadi Cerita

Ikuti latihan untuk menemukan fitur kecil yang dipahami dengan baik dan memecahnya menjadi cerita pada awalnya. Perkirakan cerita-cerita ini berdasarkan poin. Sekarang Anda punya dasar di mana

Kecil -> 40 poin

Ini akan menjadi dasar perbandingan dengan fitur lainnya

Kaitkan upaya titik cerita ke semua Fitur

Bandingkan Fitur Kecil Anda dengan fitur lainnya. Sebagai contoh,

Fitur Sedang Y terasa seperti dua kali ukuran dan upaya Small Feature X dengan 40 poin cerita.

Fitur Sedang Y mungkin 80 poin cerita. Lanjutkan ini sampai Anda memiliki poin cerita diperkirakan pada tingkat tinggi untuk semua fitur.

Perkirakan Kecepatan Tim Anda

Melihat tim pengembangan Anda, cobalah untuk menentukan berapa banyak poin cerita yang tim ini dapat berikan secara efektif dalam sprint yang diberikan. Jika Anda memiliki proyek Agile sebelumnya sebagai contoh dengan tim ini, itu adalah tempat yang bagus untuk memulai. Jika Anda tidak memiliki riwayat seperti itu di belakang tim, maka lakukan perencanaan Sprint tiruan dengan tim Anda di mana Anda mulai melihat fitur Kecil Anda yang telah Anda perinci. Perkiraan jam seperti apa yang diberikan orang untuk tugas mereka pada cerita-cerita ini?

Berdasarkan seberapa banyak kerja yang menurut tim dapat mereka hasilkan dalam 2 minggu, gunakan angka total poin cerita sebagai kecepatan potensial rata-rata tim Anda!

Temukan Tanggal Penyelesaian yang Diproyeksikan

Jika tim Anda dalam perencanaan sprint mock merasa nyaman memberikan 25 poin cerita dalam sprint, dan total simpanan Anda terlihat seperti 300 poin cerita untuk versi Cadillac emas proyek Anda, maka sepertinya tim Anda idealnya akan mengambil 12 sprint atau 24 minggu untuk menyelesaikannya. lengkapi semuanya.

Sekarang sepele untuk mengubah biaya sumber daya di tim Anda menjadi dolar per minggu untuk sampai pada biaya untuk ROI vs Nilai Bisnis. Negosiasi dapat berlanjut pada apa fitur yang paling penting dan kemudian manajemen proyek Anda pada dasarnya menjadi Masalah Knapsack.

maple_shaft
sumber
2
+1 untuk menjadi satu-satunya orang (sejauh ini) yang benar-benar menjawab pertanyaan.
RubberDuck
2
Saya pikir jawaban ini menyoroti fakta bahwa sementara manajemen tidak masuk akal untuk mencoba menentukan ROI, mereka menjadi tidak masuk akal (atau setidaknya, sangat tidak realistis) jika mereka mengharapkan perkiraan di muka seperti itu akan jauh akurat dalam praktiknya. Jawaban ini memberikan penjelasan yang baik tentang bagaimana memperkirakan tanggal rilis di bawah Agile. Tapi saya berasumsi OP sudah tahu bagian itu, dan bertanya lebih banyak tentang bagaimana Anda dapat memberikan estimasi akurat yang akurat di muka dalam konteks Agile (atau lainnya). Jawaban singkatnya adalah Anda tidak bisa; itulah sebabnya orang menggunakan Agile sejak awal.
Agustus
@aroth Shhhh! Jangan berikan rahasia kepada Normandia! Meskipun dengan keseriusan Anda benar tentang perkiraan tetapi setidaknya Agile baik dalam membandingkan kompleksitas relatif dan dapat memungkinkan pilihan sulit dibuat dengan informasi lebih lanjut. Perangkat lunak adalah bisnis yang berantakan dan berisiko dan bagi saya tampaknya tidak ada yang lain yang memberikan ide yang lebih baik tentang apa yang diharapkan pada proyek jangka panjang.
maple_shaft
10

Ini bukan masalah dengan "manajemen". Merupakan syarat mutlak untuk dapat memperkirakan biaya dan manfaat dari setiap proyek potensial sebelum memulai. Kalau tidak, bagaimana orang tahu apa yang pantas dilakukan (atau dicoba)?

Lalu mengapa Agile?

Saya berpendapat bahwa menggunakan metode Agile bukan untuk memilih ketidakpastian. Sebaliknya, Agile adalah argumen bahwa ketidakpastian tidak dapat dihindari, dan spesifikasi terperinci dan perkiraan metode tradisional memperkenalkan kepastian yang salah - yang bisa sangat mahal.

Beberapa poin kunci dalam hal estimasi waktu:

  • Perubahan persyaratan di seluruh proyek tidak bisa dihindari; Agile memperhitungkan hal ini daripada pura-pura tidak akan ada perubahan.
  • Spesifikasi terperinci sering mengandung cacat desain yang tidak terungkap sampai memasuki proyek. Ini mungkin berarti perubahan yang lebih besar dalam proyek tradisional daripada proyek Agile.
  • Perkiraan waktu berdasarkan "seberapa besar hal yang menurut saya seluruh proyek ini?" mungkin sama akuratnya dengan menambahkan perkiraan waktu untuk banyak persyaratan terperinci.
  • Hal utama yang mengarah pada perkiraan yang baik adalah siklus memperkirakan, mengukur, dan meninjau - yang dapat diterapkan pada proses yang konsisten.
  • Perkiraan "pekerjaan yang diselamatkan" akan didorong oleh persyaratan utama untuk proyek dan bukan perinciannya, jadi saya ragu Agile akan sangat membahayakan kemampuan untuk memperkirakan ini.

Memperbarui:

Hanya untuk memperjelas, respons Anda kepada bos Anda tampaknya adalah "Kami tidak dapat memperkirakan waktu yang dihemat atau upaya pengembangan total dengan sangat baik menggunakan Agile, karena fleksibel." Saya pikir ini salah. Saya percaya perkiraan ini dapat dibuat dengan baik ketika menggunakan proses Agile, karena ketidakpastian ada di sana. Dan tentu saja Agile memungkinkan proses yang lebih fleksibel dan responsif saat proyek dibuka.


sumber
Terima kasih untuk ini. Saya menghargai bahwa seluruh titik Agile adalah memanggang ketidakpastian ke dalam proses. Yang mengkhawatirkan saya adalah saya pikir saya telah membantu orang lain memahami hal ini tetapi sejumlah persyaratan terbaru saya menyarankan sebaliknya.
Bob Tway
@MattThrower, saya telah menambahkan beberapa pemikiran lebih lanjut untuk jawabannya, karena saya tidak yakin apa yang saya coba katakan.
8

Ini tentu saja salah satu bagian tersulit dalam memperkenalkan Agile

"Manajemen masih membutuhkan perkiraan waktu"

Pendekatan saya adalah:

  • Pad 300%. Ungkapan lama 300% berguna ketika Anda berada dalam situasi di mana menjadi sangat gesit di tingkat manajemen tidak akan terjadi. Ini mungkin bukan "pendekatan gesit" tetapi merupakan kompromi untuk situasi ini. Anda akan bisa maju beberapa kali - tetapi jangan mengandalkan itu!

  • Mintalah ulasan berdasarkan pekerjaan yang dicapai pada titik proyek 'setengah jalan'. Proyeksikan kapan Anda akan selesai berdasarkan pekerjaan yang dilakukan. Kemudian berbicara dengan manajemen dan pergi ke mana mereka yang harus mengorbankan - fungsionalitas atau kualitas - mengingat waktu itu ditetapkan berdasarkan tebakan pada awal proyek.

  • Pastikan Anda berkolaborasi pada fitur yang dilakukan dan berkualitas dengan manajemen sehingga mereka benar-benar membuat keputusan tersebut

  • Ikuti arus untuk proyek ini dan biarkan hal-hal biasa terjadi - tenggat waktu yang terlewati, kualitas yang buruk, terbakar dan membuat stres (dan mungkin diberangkatkan) karyawan yang pergi. Ketika proyek fase berikutnya muncul, bahas 'efek samping' ini.

  • Fokuskan dan tunjukkan keunggulan pendekatan tangkas yang "benar". Bicara tentang peningkatan kualitas. Bicaralah tentang kemampuan untuk membuat perubahan di akhir hari sampai dan melewati mereka untuk berproduksi. Bicara tentang lebih sedikit kebutuhan untuk bekerja kembali. Bicara tentang utang kurang teknis yang pada akhirnya akan membawa merangkak. Buat analogi dengan dunia nyata, misalnya, kita dapat menunda penggantian oli setiap hari, tetapi menunda cukup lama dan mesinnya menderita, berkinerja buruk, dan pada akhirnya pukulan batang.

  • Tetap perbarui resume Anda dan profil tertaut dalam. Jika Anda tidak bisa mendapatkan dukungan manajemen setelah membuat kasus Anda beberapa kali, lanjutkan. Beberapa organisasi tidak akan terdaftar dalam argumen Anda, jadi pindahlah ke yang melakukannya. Menyebutnya pekerjaan Darwinisme;)

Michael Durrant
sumber
Peluru pertama Anda dikenal sebagai Prinsip Scotty, dan 400% :-)
corsiKa
Sementara saya setuju sampai batas tertentu dengan aturan 300%, haruskah kita melakukan itu selamanya ? Dengan siklus estimasi, pengukuran, tinjauan yang berkesinambungan, tidakkah kita pada akhirnya akan menjadi lebih baik?
2
@ dan1111 Dalam pengalaman saya, lincah atau tidak, tidak itu tidak. Estimasi yang berlebihan bukan karena Anda benar-benar memperkirakan proyek, tetapi kami selalu memperkirakan seberapa produktif kami dan memperkirakan tantangan yang terlibat.
corsiKa
1
@ dan111: Setelah Anda memiliki kecepatan yang diukur cukup konsisten , maka perkiraan proyek Anda dapat didasarkan pada poin / sprint. Tetapi naluri "itu akan memakan waktu sekitar satu jam dari pekerjaan yang sebenarnya" akan selalu perlu diisi karena seperti kata korsiKa dibutuhkan lebih dari satu jam untuk melakukan satu jam dari pekerjaan yang sebenarnya. Satu-satunya hal yang tersisa untuk diputuskan adalah apakah programmer harus memberikan perkiraan "kemungkinan waktu berlalu" alih-alih perkiraan "upaya aktual yang diperlukan" di tempat pertama atau apakah yang harus diserahkan ke proses formal, yang akan mencakup faktor pengisi dari 300% atau apa pun yang diukur.
Steve Jessop
3

Saya pikir Anda membuat asumsi yang salah tentang pengembangan Agile. Fleksibilitas dan persyaratan yang berubah secara harfiah dimasukkan ke dalam Agile Manifesto .

Selamat datang perubahan persyaratan, bahkan terlambat dalam pengembangan. Proses tangkas memanfaatkan perubahan untuk keunggulan kompetitif pelanggan.

Persyaratan fleksibel (baca: berubah) diterima di Agile. Memang jika Anda meminta sebagian besar pengembang mereka akan menambahkan peringatan bahwa perubahan itu harus masuk akal. Meminta tim untuk membuat game 3D lalu mengubah persyaratan menjadi "sistem kontrol untuk reaktor nuklir" agak banyak. Tetapi menambahkan, menghapus, atau memodifikasi persyaratan dalam ruang lingkup proyek sangat baik.

Pertanyaannya adalah bagaimana Anda mengatasi perubahan persyaratan? Jawaban khasnya adalah menggunakan iterasi singkat sehingga Anda dapat membuat penyesuaian kursus sejak awal sebelum Anda membuang terlalu banyak waktu. Ini juga memaksa tim untuk menguraikan persyaratan menjadi bagian-bagian yang lebih kecil sehingga semua orang dapat lebih memahami mereka dan mengimplementasikannya dalam jumlah waktu dan upaya yang wajar.

Kesederhanaan - seni memaksimalkan jumlah pekerjaan yang tidak dilakukan - sangat penting.

Saya juga suka prinsip Agile ini. Ini biasanya diartikan bahwa sebuah tim harus berusaha untuk hanya memberikan hal-hal yang diperlukan melalui efisiensi yang kejam. Misalnya: jika pelanggan berpikir mereka membutuhkan sesuatu tetapi tampaknya mencurigakan, gali sekitar. Mungkin pengguna akhir benar-benar tidak ada gunanya, jadi pekerjaan itu tidak boleh dilakukan.

Namun, saya pikir pertanyaan Anda mengenai aspek lain dari prinsip ini. Perangkat lunak umumnya melayani tujuan mengotomatiskan proses manual. Perangkat lunak itu sendiri ada untuk memaksimalkan jumlah pekerjaan yang tidak dilakukan - oleh pengguna akhir.

Mengukur jumlah tenaga kerja yang akan dihemat perangkat lunak pengguna akhir jelas merupakan metrik yang layak. Saya mengukur ini sendiri dalam karier saya. Ini sebenarnya merupakan komponen penting dari analisis biaya / manfaat: berapa banyak upaya yang akan dilaksanakan proyek perangkat lunak, dibandingkan dengan seberapa banyak upaya produk akhir akan menyelamatkan pengguna akhir.

Ini benar-benar kompatibel dengan filosofi pengembangan Agile (atau lainnya) dan manajemen Anda benar-benar harus setuju dengan ini.


sumber
1
Saya mengerti ini. Saya tidak yakin semua orang dalam bisnis itu.
Bob Tway
2
@MattThrower: Dari apa yang saya mengerti dari pertanyaan Anda, manajemen Anda meminta Anda untuk memberikan analisis biaya / manfaat, seperti yang dijelaskan di bagian kedua dari jawaban ini. Mereka mungkin perlu untuk dapat mengalokasikan dana / orang untuk proyek di tempat pertama.
Bart van Ingen Schenau
@MattThrower Agile bukan argumen terhadap perkiraan waktu. Jika kemudian melacak metrik seperti Velocity akan menjadi tidak berarti karena mereka tidak memiliki faktor prediktif untuk kesuksesan masa depan. Apa yang Agile berikan adalah lebih banyak wawasan dan negosiasi tentang prioritas bisnis pada suatu proyek. Mereka masih membutuhkan perkiraan untuk setiap tonggak sejarah untuk melakukan diskusi itu
maple_shaft
2

Ya, kelincahan memiliki beberapa keunggulan.

  • Ini memungkinkan para pelaku bisnis untuk mengubah pikiran mereka di tengah penerbangan.
  • Ini semacam melindungi bisnis terhadap perkiraan buruk insinyur yang terus-menerus.
  • Ini memberikan nilai awal dan sering, sebelum visi akhir tercapai.
  • Ini memberi Anda beberapa biaya perencanaan di muka, yang seringkali dapat menghasilkan rencana yang buruk pula .
  • Sangat keren. Kanan?

Namun, Anda masih perlu memberikan perkiraan awal yang cukup akurat.

Jika tidak, Anda secara efektif meminta bisnis untuk berinvestasi dalam produk Anda tanpa bukti bahwa produk Anda bahkan sepadan dengan investasi awal - dan dalam beberapa kasus, apa saja.

Dan saya bisa mendengarnya sekarang.

Saya pernah mendengarnya sebelumnya. Saya cukup yakin saya pernah mengatakannya sebelumnya:

Oh - Tapi Haow !? Bagaimana seorang manusia biasa seperti saya memandang mata saya akan nasib hal-hal seperti itu! Hal-hal yang hanya dapat dilakukan oleh dewa sendiri dan langsung. Hal-hal yang hanya dapat diimpikan oleh manusia fana dalam tidur nyenyak dan melupakannya pada siang hari! Oh tipe manajerial yang kejam, HAOW, bisakah tuntutan seperti itu dipenuhi !?

Gunakan kinerja masa lalu Anda sebagai panduan dan jujur .

  • Memiliki cukup banyak percakapan dengan pemangku kepentingan dan / atau pengguna akhir untuk menentukan seberapa rumit produk dan / atau komponen utamanya relatif terhadap komponen utama lain yang telah Anda kerjakan. Buat estimasi titik relatif awal.
  • Mengembang nomor itu dengan jumlah historis perubahan ruang lingkup dan dampak bug yang Anda lihat secara historis.
  • Terapkan kecepatan historis Anda ke estimasi titik untuk sampai pada garis waktu kasar. Dan, terapkan kerucut ketidakpastian yang masuk akal .
  • Tinjau kembali estimasi dan pemahaman Anda tentang proyek. Yakinlah bahwa Anda akan bersedia mengambil keputusan tentang menangani proyek berdasarkan penilaian Anda.

Akhirnya, berikan kerucut ketidakpastian Anda kepada para pemangku kepentingan, nyatakan asumsi dan kekhawatiran Anda, dan biarkan saja.

Selain itu, saya juga menyarankan datang dengan heuristik titik-estimasi obyektif untuk kewarasan-memeriksa Anda dan / atau estimasi normal tim Anda.

Anda dapat menggunakan estimasi ini sebagai suara ke- N selama perencanaan poker, atau dalam memvalidasi estimasi pribadi Anda jika Anda melakukan solo. Misalnya, tim saya cenderung memperkirakan sekitar 1 poin per menit dari diskusi penemuan teknis yang longgar tentang sebuah cerita. Ini sangat membantu jika nyali Anda memberi tahu Anda sebuah cerita adalah 5 poin, tetapi Anda membutuhkan waktu 20 menit untuk memahami apa yang perlu dilakukan - biasanya merupakan indikator yang baik bahwa masih ada kerumitan dan kesalahpahaman yang bersembunyi.

svidgen
sumber
1

Saya tidak pernah bekerja di perusahaan mana pun yang dapat memiliki perkiraan waktu yang baik secara konsisten, dan saya juga tidak pernah bekerja dengan siapa pun yang mengklaim telah melakukannya. Pencarian akan menunjukkan kepada Anda bahwa estimasi adalah masalah yang belum terpecahkan di seluruh industri.

Saya akan mencoba untuk menerima tentang mengukur kecepatan berdasarkan poin cerita abstrak, dan jika Anda tidak bisa melakukan itu, saya akan menambah perkiraan Anda.

Daenyth
sumber
Saya tidak pernah bekerja untuk Perusahaan yang setuju untuk memulai suatu proyek tanpa beberapa gagasan tentang berapa biayanya dan berapa banyak itu akan menghasilkan.
Paul Smith
1
Saya / pernah / bekerja di perusahaan yang memiliki perkiraan waktu yang sangat baik. Tetapi mereka adalah perusahaan jasa profesional yang berulang kali mengirimkan proyek yang sebanding, dan mereka banyak berinvestasi dalam metodologi. Di luar sektor itu, jarang terjadi.
Alfred Armstrong
1

Agile adalah solusi hebat untuk berbagai masalah, tetapi terlepas dari apa yang disarankan beberapa evangelis, itu bukan satu-satunya solusi dan itu tidak selalu merupakan solusi yang tepat.

Kasus yang Anda nyatakan bukan masalah lincah:

Baru-baru ini saya ditugasi untuk berkeliling tim dan meminta mereka untuk ide tentang proses bisnis untuk diotomatisasi. Saya kemudian mencari tahu berapa banyak waktu yang dihabiskan untuk mereka, mencari tahu berapa banyak waktu solusi akan menghemat dan memperkirakan total waktu pengembangan. Dengan begitu, manajer dapat mencoba mengukur seberapa efektif suatu solusi dalam hal menghemat waktu.

Anda ditugasi menentukan biaya dan manfaat dari mengotomatisasi beberapa proses bisnis, yang bukan tugas gesit yang dapat berubah, itu adalah masalah khusus dengan solusi spesifik. Anda akan menghasilkan daftar dengan jumlah proses bisnis yang sewenang-wenang dan untuk masing-masing, akan ada perkiraan biaya otomatisasi, perkiraan biaya tidak mengotomatisasi dan perkiraan manfaat mengotomatisasi. Manajemen akan mencocokkan ini dengan anggaran, sumber daya, persyaratan, dan sasaran strategis mereka dan menentukan mana (jika ada) dari proses ini yang akan diotomatisasi. Jika Anda teliti, maka Anda akan menyoroti tugas-tugas yang dipilih yang berpotensi menurunkan ROI dalam diri mereka sendiri tetapi yang akan mengurangi biaya fase lain sehingga meningkatkan total ROI. Anda mungkin juga telah mengidentifikasi berbagai cara untuk mencapai otomatisasi termasuk pengembangan dipesan lebih dahulu in-house dan outsourcing (menggunakan teknik lincah dan / atau air terjun), membeli solusi rak, menggunakan penyedia layanan pihak ketiga dan sebagainya. Seluruh proses ini sangat populer di tahun 90-an ketika dikenal sebagai rekayasa ulang proses bisnis.

Paul Smith
sumber