Görevli ve onaylı istekler

“A new colleague is starting” tek bir talep değildir. Bir dizüstü bilgisayar, iki hesap, bir telefon dahilisi ve belki dışarıdan erişimdir. Her parça başka bir ekibe aittir ve siz yine de işlerin nerede durduğunu söyleyen tek bir iş istersiniz.

Bir istek bunun içindir. Açıldığı anda görevlerini oluşturan bir taleptir ve her görev, onu yürüten ekipte kendi talebine dönüşür.

Bir istek, bakımı yapılacak ikinci bir şey değildir. Bir talep şablonunun üzerinde yaşar: “Settings → Request workflows” altında her talep şablonunu bulursunuz ve görevleri onlardan birine eklersiniz.

Her görev için birkaç alan doldurursunuz. “Task” talep edenin okuduğu addır, “Handled by” onu alan ekiptir, “Ticket title” ve “What the team has to do” ise ondan çıkan talebi doldurur.

Birden çok görev aynı ekibi gösterebilir. O ekip o zaman birden çok talep alır, içinde liste olan tek bir talep değil.

Ekipsiz bir görev hiç sunulmaz. Alanın kendisi bunu söyler: “Not assigned yet — this task is not offered”. Böylece henüz bitmemiş bir planı kaydedebilirsiniz.

Görevlerin üstünde planın tamamını özetleyen bir cümle durur: fabrika ayarı olarak neyin oluşturulduğu, talep edenin ne kadarını değiştirebileceği ve kimin onayladığı. Bir ayarı değiştirin, cümle kendini yeniden yazar.

“Ticket title” alanının önünde sabit “Parent ticket title -” metni durur. Yeni talep isteğin başlığıyla başlar, ardından sizin başlığınız gelir, örneğin “New colleague in accounting - Set up notebook and docking station”. Böylece uzman ekip, bir görevin hangi isteğe ait olduğunu görür. Alanı boş bırakırsanız onun yerine görevin adı gelir.

“Main category” ve “Subcategory” alanları yeni talebin kategorisini önceden doldurur. Yalnızca “Handled by” alanındaki ekibin kategorilerini alırsınız, çünkü talep orada oluşturulur. Ekibi değiştirirseniz iki alan da temizlenir. İkisini de ayarlarsınız ya da hiçbirini; boş kalırlarsa talep kategorisiz oluşturulur.

İsteğin adı görevlerin üstünde durur. Yeniden adlandırmak için yanındaki kalemi kullanın. Ad talep şablonuna aittir, bu yüzden “Settings → Templates” altında ve yeni talep formunda da değişir.

Biri yeni talep formunda şablonu seçtiğinde, görev başına işaretlenecek birer satırla “What is needed?” kutusu belirir.

Görev başına ayarlanan üç tür vardır. “Selectable, off by default” boş başlar, “Selectable, on by default” işaretli başlar ve işareti kaldırılabilir, “Always — cannot be deselected” ise her zaman çalışır.

Her zaman çalışan bir görev yine de gösterilir, “(always included)” olarak işaretlenerek. Talep eden zaten olacak olanı görmelidir.

Kutunun altında bundan ne çıkacağını okursunuz: “Each selected item becomes its own ticket for the team that handles it.”

Şablon müşterilere açıldıysa bir müşteri de istek açabilir. Bunun anahtarı şablonda durur.

Müşteri o zaman yalnızca kendi isteğini görür. Uzman ekiplerdeki talepler, isteği onları oluşturmuş olsa da ondan gizli kalır; o talepler erişim bilgileri ve dahili notlar taşır. Onların dahili notları isteğin geçmişinde de görünmez. Bir uzman ekip kendi talebini kapattığında ekleri “Internal” rozetiyle isteğe kopyalanır ve müşteri onları ne görür ne de indirebilir.

Bir istek e-postayla gelirse sıradan bir talep olur. İş akışını o zaman sonradan başlatırsınız. Bunu talebin üst kısmındaki “Start workflow” düğmesi yapar.

İletişim kutusunda “Template” altında uygun şablonu seçersiniz. Altında yeni talep formundakiyle aynı “What is needed?” kutusunu bulursunuz. İsteğin istediklerini işaretleyin.

“Title” altında talebin başlığını düzenlersiniz. Görevlerin başlıkları onunla başlar. Onun altında şablonun ek alanlarını bulursunuz. İstekteki bilgileri oraya girin. Zorunlu alanlarda bir yıldız vardır.

“Start” ile görevler, formdan gelen bir istekte olduğu gibi oluşturulur. Şablon bir onay gerektiriyorsa talep ve görevleri, onay verilene kadar kilitli kalır.

Bir talepte yalnızca bir iş akışı başlatılabilir. Ardından düğme kaybolur. Kapalı taleplerde ve kendisi bir görev olan taleplerde de bulunmaz. Talep üzerinde çalışma yetkisi olan herkes iş akışını başlatabilir.

İsteğin kendisinde görevler “Workflow tasks” altında listelenir, yanında sayısıyla birlikte, örneğin “1 of 4 done”.

Her satır görevin adını, talebinin numarasını, ekibi ve atanan kişiyi gösterir ve ad, o talebe giden bir bağlantıdır.

“Done” bilgisi ayrı bir işaretten değil, talebin durumundan gelir. Talep listesinde kapanmış sayılan burada da bitmiş sayılır; aynı şeyi saymanın iki yolu er ya da geç birbirinden ayrılırdı.

Blok yalnızca bir istekte görünür. Sıradan bir talep onu göstermez.

Bir uzman ekip kendi talebini kapattığında ekibin yazdığı “Closing comment” isteğe ulaşır. Orada dahili not olarak durur ve ilk satırı görevin numarasını ve adını belirtir. Müşteri bu notu görmez.

Erişim bilgileri ve isteğin temsilcisinin iletmesi gereken her şey kapanış yorumuna girer. Uzman ekibin diğer tüm yorumları kendi talebinde kalır. Ekip yorum yazmadan kapatırsa not oluşturulmaz.

Bir onay tek tek görevi değil, isteğin tamamını kapsar. Sekiz uygulama, amire sekiz değil bir posta demektir.

Bunu aynı planda “Approvals” altında kurarsınız ve üstündeki cümle kuralı belirtir: “One approval covers the whole request. Add a second stage only when single tasks need their own release.” Her aşamanın beş alanı vardır: “Name” aşamanın adıdır, “Covers” neyi kapsadığını, “Decided by” onaylayanın nereden geldiğini söyler, “Approver” kişiyi taşır ve “Remind after (hours)” hatırlatmayı ayarlar.

Onaylayanın talep sisteminde hesaba ihtiyacı yoktur: bir e-posta adresi girersiniz ve o, bir bağlantı üzerinden karar verir. Üç ayda iki kez onay veren bir amir bu yüzden temsilci kontenjanına mal olmaz.

Posta tam olarak bir sayfaya giden tek bir bağlantı içerir. Postanın kendisinde bilinçli olarak onay ya da ret düğmeleri yoktur: her bağlantıyı açan bir virüs tarayıcısı yoksa onay verirdi.

Sayfa başlık olarak aşamanın adını taşır. İsteğin numarasını ve başlığını, talep edeni ve “This decision covers” altında bu kararın konusu olan görevleri gösterir, altında bir yorum alanı ve iki düğmeyle.

Bağlantı sonsuza kadar sürmez ve sayfa son tarihi adlandırır: “Please decide by …”. 14 gün geçerlidir. Sonrasında sayfa yalnızca bağlantının geçersiz olduğunu ya da süresinin dolduğunu söyler ve bir yönetici isteği “Reassign” ile yeniden gönderir.

Bir karar geri alınamaz ve sayfa sonrasında bunu söyler: “A decision cannot be changed.”

Bazı görevler kendine ait bir onay ister. Dışarıdan erişim, bir dizüstü bilgisayarla aynı şey değildir.

Bunun için ikinci bir aşama ekler ve onu görevde “Extra approval” altında seçersiniz. Orada “None — the request approval is enough” yazdığı sürece isteğin onayı yeterlidir. İki aşama art arda değil, aynı anda sorulur. Bir aşama ancak seçilen görevlerden biri onu ilgilendiriyorsa sorulur. Tüm isteğe ait aşama her zaman sorulur.

Bir görev, kendisini ilgilendiren her aşama olur dediğinde serbest kalır. Kendi aşaması olmayan bir görev, tüm isteğe ait aşama hâlâ beklemiyorsa hemen başlar. Bekliyorsa istek onaylanır onaylanmaz başlar.

O zamana kadar görev kilitlidir. Talebi “Waiting for approval” üzerinde durur ve atanan kişisi yoktur. Durum düğmeleri yerine kartta “This ticket is waiting for approval and cannot be worked on yet.” yazar. O zamana kadar hiçbir yol ona atanan kişi vermez.

Kilit, talep listesindeki toplu işlemler için de geçerlidir. Orada böyle bir talebi seçtiğinizde nedenini okursunuz: “This ticket is waiting for approval and cannot be worked on yet.”

Talep yine de hemen oluşturulur, böylece uzman ekip neyin geldiğini görür ve kimsenin isteği gözlemesi gerekmez.

Aşama başına saat cinsinden bir hatırlatma ayarlayabilirsiniz.

Yanıt gelmezse o süre sonra aynı posta yeniden çıkar ve birincisiyle aynı bağlantıyı taşır. İlk postayı saklayan onu yine kullanabilir.

Hatırlatma olmadan istek yeniden sormadan öylece bekler.

Olmayan şey, süre dolduğunda verilen onaydır. Alanın altında bu açık açık yazar: “A request is never approved automatically. If nobody reacts, it keeps waiting.” Kendiliğinden olur diyen bir süre, bir onay değil, bir formalite olurdu.

Reddetmek bir gerekçe ister. Metin olmadan sayfa reddi kabul etmez.

Alan, metnin nereye gittiğini söyler: “Comment (required when you reject — the requester will see it)”. Dahili bir not buraya ait değildir.

Talep eden gerekçeyi içeren bir e-posta alır ve neden bir şeyin ilerlemediğini sormak zorunda kalmaz.

Onay vermek gerekçe istemez. O, beklenen sonuçtur.

Yalnızca ikinci bir aşama reddederse ret, yalnızca o aşamanın görevlerini ilgilendirir. İsteğin geri kalanı yoluna devam eder.

Reddedilen bir görev “Rejected” durumunu alır ve bitmiş sayılır, böylece istek hiçbir zaman gelmeyecek bir şeyde sonsuza kadar asılı kalmaz.

İstek reddedildiğinde diğer onaylayanlar artık posta almaz. Bağlantılarında o zaman “This request has already been rejected. Your decision is no longer needed.” yazar. Talepteki listede onların aşaması “No longer needed: the request was rejected.” gösterir.

İstekte “Approvals” aşama başına bir satır gösterir: onaylayan, durum ve açık bir istekte ne kadar süredir beklediği.

Karardan sonra satır kararın ne zaman ve hangi yorumla verildiğini gösterir. Denetim izi budur ve işle birlikte kalır.

Onaylayan izindeyse bir yönetici isteği başka bir adrese taşır. Düğmenin adı “Reassign” şeklindedir ve yalnızca istek açıkken görünür.

Bunu yalnızca bir yönetici yapabilir. Yeniden atayabilen bir temsilci, isteği kendine atayıp sonra karar verebilirdi.

Yeniden atama yeni bir bağlantı oluşturur ve eskisi hemen ölür, biri onu iletmiş olsa bile.

Taşımanın kendisi aynı listede görünür: kim taşıdı, ne zaman, kimden kime.

Kimse bir başkasının adına karar veremez. Tek yol bağlantıdır ve onu kimin aldığı işte kayıtlıdır.