Galvenie secinājumi:
Rakstā norādīts, ka problēma sākas nevis ar trūkstošām funkcijām, bet gan tur, kur sistēma izkropļo procesa faktisko norisi. Šādos apstākļos specializēts risinājums var būt nepieciešams, lai saglabātu izsekojamību, datu konsekvenci un operatīvo kontroli.
- Gatava ERP sistēma darbojas tad, ja process ir atkārtojams un datu modelis precīzi atspoguļo ražošanu bez būtiskiem vienkāršojumiem.
- Pazīmes, kas liecina par neatbilstību, ir apvedceļi: izklājlapas ārpus sistēmas, manuāla datu pārrakstīšana un izņēmumi, kas tiek apstrādāti ārpus sākotnējā reģistra.
- Visdārgākās sekas rodas ražošanas, kvalitātes, tehniskās apkopes un procesa drošības saskarē.
- Specializētai programmatūrai ir jēga tad, ja nepieciešams saglabāt procesa, avota datu un operatīvo lēmumu vienotību.
- Lēmums par “gatavs vai pielāgots risinājums” jābalsta uz izņēmumu, risku un kontroles punktu analīzi, nevis uz funkciju katalogu.
Gatavs MES vai ERP risinājums var būt saprātīga izvēle, taču tikai tad, ja reālo ražošanas gaitu iespējams atspoguļot bez būtiskiem vienkāršojumiem. Pretējā gadījumā sistēma sakārto uzskaiti uz procesa vadāmības rēķina. Tas ir brīdis, kad jautājums par funkciju katalogu vairs nav būtisks. Jāizvērtē, vai uzņēmums joprojām pārvaldīs savu ražošanu, kvalitāti un tehnisko uzturēšanu, vai arī sāks pielāgot darbu rīka ierobežojumiem. Ja kritiskie lēmumi, izņēmumi un bloķēšanas mehānismi galvenokārt darbojas ārpus sistēmas, rūpniecībai paredzēta pielāgota programmatūra nav kaprīze. Tā kļūst par veidu, kā atjaunot datu vienotību, atbildību un operatīvo kontroli.
Ne katru ražošanu var korekti ietilpināt gatavā sistēmā
Gatava MES vai ERP sistēma labi darbojas tur, kur process patiešām ir atkārtojams, atbildības ir nepārprotami noteiktas un datu modelis nekropļo uzņēmuma reālo ainu. Šādos apstākļos standartizācija sakārto informācijas apriti, samazina lokālu interpretāciju skaitu un ļauj pieņemt lēmumus, balstoties uz vienotu notikumu uzskaiti. Problēma parādās agrāk nekā trūkstošu funkciju līmenī. Tā sākas tur, kur ražošanas, kvalitātes, tehniskās uzturēšanas un plānošanas faktiskā norise vairs neiekļaujas sistēmas loģikā bez zaudējumiem procesam.
Tā ir robeža starp saprātīgu standartizāciju un operatīvās kontroles zaudēšanu. Ja organizācija sāk apiet savu procesu tikai tāpēc, lai dati “sakristu sistēmā”, informācijas arhitektūra vairs nekalpo ražošanai. Tā sāk to deformēt. Daļu noteikumu var droši vienādot ar konfigurāciju vai procedūru, taču ir arī tehnoloģiskās sakarības, kontroles punkti un atbildības ceļi, kurus nedrīkst izpludināt, nekaitējot produkta kvalitātei, procesa drošībai vai lēmumu izsekojamībai. Tāpēc strīds “gatavs vai savs” parasti ir formulēts nepareizi. Precīzāks jautājums ir šāds: kuri procesa elementi ir kopīgs standarts, bet kuri veido uzņēmuma priekšrocības būtību, ir riska avots vai atbilstības pienākumu joma un tādēļ ir jāatspoguļo precīzi.
Praksē visdārgākie nav trūkstošie moduļi, bet gan apiešanas risinājumi, kas nemanāmi kļūst par ikdienas darba veidu. Tabulas, kas tiek uzturētas paralēli sistēmai, manuāla datu pārrakstīšana starp maiņu un biroju, operatoru piezīmes, neformāla izņēmumu saskaņošana un paralēlas informācijas plūsmas nav sīka neērtība. Tas ir signāls, ka procesa vadības modelis sāk plaisāt. Šādā situācijā ir vērts mērīt nevis funkciju skaitu, bet manuālo datu pārrakstīšanas punktu skaitu starp ražošanu, kvalitāti, tehnisko uzturēšanu un plānošanu, ārpus sistēmas apstrādāto kritisko izņēmumu skaitu, kā arī to operatīvo lēmumu īpatsvaru, kas tiek pieņemti, balstoties uz datiem, kuri nenāk tieši no primārā reģistra. Ja šie rādītāji pieaug, problēma parasti nav vājā konfigurācijā, bet kļūdainā pieņēmumā, ka procesu var bez izmaksām pielāgot rīkam.
To labi var redzēt uzņēmumos, kuros pasūtījuma izpilde ir atkarīga ne tikai no tehnoloģiskā maršruta, bet arī no mašīnas faktiskā stāvokļa, starpoperāciju kontroles rezultātiem, materiālu pielaidēm, izejmateriāla partijas, iestatījumu parametriem un lēmumiem, ko laika spiediena apstākļos vienlaikus pieņem vairākas struktūrvienības. Ja gatava sistēma nespēj uzturēt šīs sakarības vienā uzticamā datu ķēdē, patiesā informācija par procesu sadalās vairākās vietās. Daļa paliek sistēmā, daļa pie iekārtas, daļa kvalitātes dokumentos, bet daļa cilvēku zināšanās. Šāds stāvoklis apgrūtina ražošanas procesa kartēšanu, sarežģī ieviesēju atbildības sadalījumu un palielina projekta risku, integrējot ar automatizāciju un sistēmām, kas ietekmē mašīnu drošību. Pielāgota programmatūra ir pamatota nevis tad, kad uzņēmums vēlas “kaut ko savu”, bet tad, kad jānodrošina procesa, primāro datu un lēmumu vienotība tur, kur vienkāršošana nozīmētu reālu kontroles zudumu.
No atbilstības un operatīvās uzraudzības viedokļa šai atšķirībai ir izšķiroša nozīme. Ja galvenie noteikumi un kontroles punkti pastāv tikai komandas praksē, bet sistēma tos neuzspiež vai vismaz nepārprotami neatspoguļo, atbildības izsekojamība kļūst nosacīta. Dažās nozarēs tā galvenokārt būs kvalitātes un partijas gaitas atjaunojamības problēma, citās arī jautājums par nozares prasībām, izsekojamību, izmaiņu pārvaldību vai atbildības robežām starp uzņēmuma lietotāju, integratoru un programmatūras piegādātāju. Tāpēc lēmums pakārtot procesu sistēmai vai sistēmu procesam ir jāpieņem nevis pēc funkciju prezentācijas, bet pēc godīgas izņēmumu analīzes. Tikai tad kļūst redzams, kuri no tiem ir organizatorisks haoss un kuri atspoguļo reālas tehnoloģiskās, informatīvās un drošības prasības.
Izmaksas pieaug tur, kur sistēma neredz reālo risku
Sistēmas neatbilstība visdārgāk izmaksā nevis vienkāršā uzdevumu apritē vai ikdienas atskaitēs, bet gan ražošanas, kvalitātes, tehniskās uzturēšanas un procesa drošības saskares punktā. Tieši tur lēmums jāpieņem ātri, tam jābūt dokumentētam un balstītam uz pilnu kontekstu: iekārtas aktuālo stāvokli, partijas parametriem, iejaukšanās vēsturi, kvalitātes atbrīvošanas statusu un spēkā esošajiem bloķējumiem. Ja gatavs MES vai ERP redz tikai daļu no šīs ainas, izmaksas neaprobežojas ar lietotāja neērtībām. Parādās operacionāla mainība. Dažādas maiņas pieņem līdzīgus lēmumus, balstoties uz atšķirīgiem datiem, izņēmuma situācijas tiek risinātas pēc ieskatiem, un atbildība izplūst starp sistēmu, procedūru un ceha praksi.
Svarīgākā problēma sākas brīdī, kad sistēma neatspoguļo reālo darbību secību, bloķēšanas nosacījumus, tehnoloģisko parametru versiju pārvaldību vai atbildību par atkāpes apstiprināšanu. Ierakstos viss var izskatīties pareizi, kamēr faktiskā izpilde ir notikusi citādi. Rodas plaisa starp notikumu un tā digitālo pēdu. Tas liek pieņemt ļoti konkrētus projektēšanas lēmumus: vai kritiskajiem procesa bloķējumiem jādarbojas sistēmas līmenī vai tikai procedūru līmenī; vai dati no iekārtām ir operacionāls pierādījums vai tikai palīgmateriāls; un vai izņēmumi jāapstrādā ar iepriekš izstrādātu lēmumu plūsmu vai jāatstāj subjektīvai izvērtēšanai. Ja uzņēmums balstās uz manuāliem pierakstiem, papildu tabulām vai saskarnēm, kurām nepieciešama pastāvīga cilvēka iejaukšanās, datu uzticamība jāvērtē nevis pēc tā, vai gala atskaiti var ģenerēt, bet pēc tā, vai bez strīdiem iespējams atjaunot vienas neatbilstības, pretenzijas vai līnijas apstāšanās gaitu.
Īpašs risks atklājas uzņēmumos ar plašu iekārtu parku, kur sistēmai jāsadarbojas ar automatizāciju, operatoru darba vietām un kontroles un mērīšanas ierīcēm. Ja integrācija ar ierīcēm ir tikai daļēja, procesa datu iegūšana ir nekonsekventa, bet izmaiņu vēsture ir izkaisīta starp kontrolieri, paneli, ražošanas datubāzi un servisa piezīmēm, partiju izsekojamība un izstrādājuma ģenealoģija kļūst nosacīta. Līdzīgi ir ar tehnoloģisko izmaiņu pārvaldību. Receptūras, pielaides sliekšņa vai pārregulēšanas loģikas maiņa var būt formāli apstiprināta, taču bez konsekventas versiju pārvaldības un arhivēšanas vēlāk nav iespējams pierādīt, kura konfigurācija notikuma brīdī faktiski bija spēkā. Tā nav sistēmas arhitektūras estētikas problēma, bet gan atjaunojamības, pamatcēloņu noteikšanas un atbildības robežu jautājums starp ražošanu, tehnisko uzturēšanu, kvalitāti un integrācijas piegādātājiem.
Šādas neatbilstības izmaksas ieviešanas budžetā parasti nav redzamas. Tās atklājas vēlāk kā diagnostikas dīkstāves, manuālā darba pieaugums, pretenzijas, strīdi par notikuma cēloni un iespējas zaudēšana viennozīmīgi atjaunot procesa gaitu. Tāpēc, vērtējot risinājumu, nepietiek jautāt, vai sistēma “atbalsta ražošanu”. Jāpārbauda, cik daudz saskarņu prasa manuālu korekciju, cik kritisko parametru netiek automātiski versēti vai konsekventi arhivēti un cik daudz laika aizņem viena operacionāla incidenta rekonstrukcija. Ja atbilde ir: ilgi, nekonsekventi un ar vairāku neatkarīgu avotu iesaisti, problēma nav lietotāja ērtībā, bet riska vadāmībā. Tieši šeit rūpniecībai paredzēts pielāgots programmatūras risinājums vai vismaz īpaši izveidots slānis virs gatavas sistēmas bieži ir pamatots: nevis tādēļ, lai labāk atskaitītos par pagātni, bet lai atbalstītu drošus operacionālos lēmumus brīdī, kad uzņēmums darbojas laika un atbildības spiediena apstākļos.
No atbilstības viedokļa tas nozīmē vēl vienu lietu. Tur, kur programmatūra ietekmē lēmumu gaitu, kam ir nozīme kvalitātei, izsekojamībai vai procesa drošībai, kritisko funkciju apjomam jāizriet no reālas riska analīzes, nevis no standarta moduļu kataloga. Tas īpaši attiecas uz integrāciju ar iekārtām, izņēmuma stāvokļu apstrādi un vietām, kur sistēmai jānodrošina noteikta darbību secība vai jābloķē pāreja uz nākamo posmu. Šādās jomās ir vērts nodalīt uzskaites funkcijas no tām, kas kļūst par operacionālās kontroles elementu un prasa stingrāku projektēšanas pamatojumu, arī mašīnu drošības un integratora atbildības kontekstā.
Vispirms lēmumu projekts, pēc tam kods
Pamatots lēmums par sistēmas attīstību uzņēmumā nesākas ar funkciju sarakstu, bet ar operacionālo lēmumu karti, kurus programmatūrai jāatbalsta vai jāuzspiež. Jānosaka, kurš pieņem lēmumu, uz kādu datu pamata, kādā laikā un ar kādām sekām ražošanai, kvalitātei, izsekojamībai vai procesa drošībai. Tikai uz šī fona kļūst redzams, vai gatavs MES vai ERP aptver problēmas būtību vai tikai sakārto uzskaiti pēc fakta. Ja kritiska ir nevis pati notikuma reģistrācija, bet nākamās operācijas palaišanas bloķēšana, partijas atbrīvošanas nosacījums, mašīnas iestatījumu atbilstības apstiprinājums vai atkāpes apstrāde, jautājums nav “vai sistēmā tas ir”, bet gan “vai tā spēj nodrošināt pareizo lēmumu pareizajā brīdī”.
Šāds domāšanas veids palīdz sakārtot arī arhitektūras projektēšanu. Praksē visbiežāk sevi attaisno hibrīda modelis. Standarta ERP vai ražošanas izpildes sistēmai jāpaliek tur, kur process ir kopīgs, atkārtojams un labi aprakstāms ar nobriedušu datu modeli: plānošanā, ražošanas uzskaitē, noliktavas pārvaldībā, kā arī pasūtījumu un partiju pamatuzskaitē. Specializētam slānim ir jēga tad, ja tas pārņem konkrētajai ražotnei kritiski svarīgu loģiku: integrāciju ar iekārtām, notikumu validāciju no vairākiem avotiem, izņēmumu apstrādi, apstiprināšanas plūsmas, audita pēdu, kā arī lēmumu sasaisti ar konkrētu partiju, iekārtu un atbildīgo personu. Tomēr priekšnoteikums panākumiem ir iepriekš skaidri noteikt atbildības robežas. Komandai jāizlemj, kas pieder tehnoloģiskajam procesam un paliek automatizācijas vai vadības pusē, kas ir ERP vai ražošanas izpildes sistēmas kompetencē, ko īsteno integrācijas slānis un kam joprojām jāpaliek organizatoriskajās procedūrās.
Bez šāda sadalījuma rodas dārga improvizācija. Viens un tas pats nosacījums mēdz būt ierakstīts vairākās vietās, izņēmumi tiek risināti manuāli, un pēc dažiem mēnešiem neviens vairs nespēj nepārprotami pateikt, kura sistēma atbild par lēmumu, kas procesu bloķē vai atbrīvo. Tāpēc labs specializēts projekts nenozīmē gatava risinājuma dublēšanu mazākā mērogā. Tā uzdevums ir aizvērt konkrētu lēmumu pieņemšanas plaisu. Tādēļ jau projektēšanas posmā ir vērts sastādīt kritisko lēmumu sarakstu, kuriem šobrīd nav sistēmiska atbalsta vai piespiedmehānisma, un pēc tam to salīdzināt ar procesa izņēmumu skaitu, kas risinājumam jāapstrādā jau no pirmās palaišanas reizes. Tas ir svarīgāk par izvērstu ekrānu specifikāciju.
Praktisks piemērs ir vienkāršs. Gatava sistēma var korekti uzskaitīt ražošanu, materiālu patēriņu un noliktavas pieņemšanas, taču neaptvert specifiskus kvalitātes bloķēšanas nosacījumus, kas saistīti ar partijas nosacītu atbrīvošanu. Partija var būt formāli saražota un iegrāmatota, tomēr tai nevajadzētu pāriet uz nākamo posmu bez noteiktu pārbaužu rezultātu apstiprinājuma, līnijas pārregulēšanas stāvokļa apstiprinājuma vai novirzes novēršanas no iepriekšējās operācijas. Ja šāds nosacījums šobrīd tiek kontrolēts ar telefona zvanu, izklājlapu vai parakstu uz izdrukas, tā nav procesa estētikas problēma, bet gan atbildības vadības plaisa. Šādā situācijā visa ERP vai ražošanas izpildes sistēmas pārbūve parasti nav pamatota. Pietiek ar specializētu slāni, kas saņem datus no iekārtām un avotsistēmām, pārbauda notikumu pilnīgumu, iedarbina atbilstošo apstiprināšanas plūsmu un nodod virssistēmai nepārprotamu partijas statusu. Standarts paliek standarts, bet kritiskā loģika tiek fiksēta tur, kur to var reāli pārvaldīt un uzturēt.
Ja ražotnei vēl nav izmaksu datu, tie nav jāmin. Pietiek sākt mērīt, cik daudz laika mēnesī patērē manuālie apiešanas risinājumi, papildu saskaņošana, partiju korekcijas un neatbilstību pārbaude starp sistēmu un procesa faktisko stāvokli. Šāds materiāls ļauj atšķirt pamatotu specializētu slāni no projekta, kas tiek rakstīts katram gadījumam. Tas arī atvieglo pareizu lomu sadalījumu biznesa pusē. Par sistēmā ierakstītās loģikas apjomu nevajadzētu lemt tikai IT nodaļai vai tikai integratoram, bet kopīgi ražošanai, kvalitātei, uzturēšanas dienestam, par digitalizāciju atbildīgajām personām, kā arī tur, kur tas ir būtiski, integratora, programmatūras izstrādes uzņēmuma un uzturēšanas dienesta sadarbībai, kā arī mašīnu drošībai un darbības atbilstībai.
No projekta atbildības viedokļa tam ir vēl viena sekas. Jo tuvāk programmatūra nonāk pie procesa pārejas nosacījumiem, operāciju bloķēšanas, darbību secības pareizības vai datiem, kas nāk tieši no iekārtas, jo mazāk to var uzskatīt par neitrālu IT papildinājumu. Šādā apjomā ir vajadzīgi skaidri projektēšanas pieņēmumi, darbības un uzturēšanas robežu apraksts, izmaiņu pārvaldības noteikumi un pārbaudāma pēda par to, kurš un uz kāda pamata apstiprināja kritisko loģiku. Tāpēc pirms pirmās koda rindas uzrakstīšanas ir vērts apstiprināt ne tikai funkcionālās prasības, bet galvenokārt lēmumu projektu: ko sistēmai jāuzspiež, ko tai nedrīkst ļaut izdarīt un kurā vietā cilvēks paliek pēdējā atbildības instance.
Atbilstība ir laba projekta rezultāts, nevis dekorācija pēc ieviešanas
Rūpnieciskā ražotnē programmatūra nav neitrāls procesa papildinājums, bet daļa no tā izpildes veida. Tā var noteikt darbību secību, bloķēt pāreju uz nākamo posmu, piespiest datu pilnīgumu, virzīt apstiprināšanas plūsmu un noteikt, vai pēc notikuma būs iespējams atjaunot lēmumu gaitu un atbildību. Tāpēc atbilstība nesākas ar formālo prasību pierakstīšanu ieviešanas beigās. Tā sākas ar projektu, kurā apzināti nosaka, kādus lēmumus sistēma pieņem pati, kādus tā tikai atbalsta, kurus datus tā uzskata par saistošiem un kam pieder noteikumi, izņēmumi un izmaiņas.
Ja šāda kārtība netiek izveidota jau risinājuma arhitektūras posmā, vēlāk atsaukšanās uz kvalitātes prasībām, procesa drošību vai dokumentēšanas pienākumiem kļūst tikai formāla. Tas ir īpaši svarīgi tad, ja sistēma ietekmē lēmumus, kas ir būtiski izstrādājuma kvalitātei, procesa drošībai vai sadarbībai ar mašīnām un iekārtām. Šādā tvērumā atbilstības prasības jāsaprot operatīvi: kā nepieciešamība pēc darbības konsekvences, izsekojamības, izmaiņu kontroles un risinājuma atbilstības faktiskajam pielietojumam. Runa nav tikai par to, lai funkcija būtu pieejama, bet lai būtu iespējams pierādīt, kāpēc tā darbojas tieši šādi, kurš apstiprināja tās loģiku un kā tiek vērtētas tās izmaiņu sekas.
Visvairāk problēmu parasti atklājas nevis palaišanas brīdī, bet pēc vairākiem ekspluatācijas mēnešiem. Uzņēmums ievieš jaunu ražošanas variantu, maina pieņemšanas kritērijus, pieslēdz nākamo darba vietu vai daļu atbildības pārnes no operatora uz sistēmu. Ja iepriekš nav noteikts, kurām lēmumu un ierakstu klasēm jāatstāj auditējama pēda, ātri rodas strīds par to, kura izmaiņa ietekmēja kvalitāti, dīkstāvi vai nepareizu sistēmas reakciju. Tieši tad kļūst redzama atšķirība starp risinājumu, kas vienkārši darbojas, un risinājumu, ko iespējams pārvaldīt. Otrajā gadījumā jau iepriekš ir zināms, kuriem loģikas elementiem nepieciešama formāla apstiprināšanas kārtība, kurš uzrauga atsauces datus, kurš uztur integrāciju ar automatizācijas sistēmām un vai projekta dokumentācija ir pietiekama auditam, uzturēšanai un drošai sistēmas pārņemšanai no cita izpildītāja.
- kādus lēmumus sistēma pieņem vai līdzveido kvalitātes, drošības un sadarbības ar mašīnu jomā,
- kādiem notikumiem, izmaiņām un apstiprinājumiem jāatstāj atjaunojama izsekojamības pēda,
- kurš ir biznesa noteikumu, datu un izņēmumu īpašnieks un kurš apstiprina to izmaiņas.
Tikai pēc šādas sakārtošanas ir jēga projektu attiecināt uz tiesiskajām un normatīvajām prasībām, kas ir piemērojamas konkrētajam uzņēmumam, izstrādājumam, nozarei un integrācijas veidam ar mašīnām vai iekārtām. Polijas un Eiropas Savienības realitātē jautājums nav tikai par to, vai risinājums darbojas, bet arī par to, vai organizācija spēj pierādīt, kāpēc tas darbojas tieši šādi, uz kāda pamata noteikumi tika apstiprināti un kā tiek pārvaldītas izmaiņas, nesamazinot izsekojamību. Šīs analīzes apjoms vienmēr ir atkarīgs no pielietojuma: citādi vērtē atskaišu sistēmu, citādi loģiku, kas ietekmē procesa norisi, un vēl citādi integrāciju, kas saskaras ar mašīnas darbību, riska novērtējumu vai integratora atbildības apjomu.
Secinājums ir vienkāršs. Pielāgota programmatūra rūpniecībai ir pamatota tad, ja tā sakārto atbildību un samazina risku tieši tur, kur gatavs ražošanas izpildes vai ERP risinājums prasītu dārgus kompromisus procesa loģikā, izmaiņu uzraudzībā vai darbību izsekojamībā. Tātad runa nav par visa veidošanu no nulles, bet par tādu standarta un kritiskās loģikas nodalīšanu, lai sistēma atbalstītu uzņēmuma reālo procesu, nevis to vienkāršotu uz kvalitātes, drošības un izsekojamības rēķina.
BUJ: Pielāgota programmatūra rūpniecībai – kad gatava ERP sistēma vairs nav saprātīga izvēle
Tad, kad faktisko ražošanas gaitu nav iespējams atspoguļot bez būtiskiem vienkāršošanām. Ja komanda sāk pielāgot procesu sistēmas ierobežojumiem, pieaug operatīvās kontroles zaudēšanas risks.
Tipiski signāli ir ārpus sistēmas uzturētas izklājlapas, manuāla datu pārrakstīšana, neformāla izņēmumu saskaņošana un lēmumi, kas tiek pieņemti ārpus sākotnējā uzskaites reģistra. Tas parasti nozīmē, ka procesa vadības modelis neatspoguļo uzņēmuma faktisko darbību.
Ne vienmēr. No teksta izriet, ka problēma bieži rodas jau agrāk — procesa loģikas, atbildības un izņēmumu līmenī, kurus sistēma nespēj aptvert, nepasliktinot kvalitāti, drošību vai izsekojamību.
Tas ir nepieciešams tad, kad precīzi jāatspoguļo tehnoloģiskās savstarpējās atkarības, kontroles punkti, bloķēšanas mehānismi un atbildības ķēdes. Runa nav par “kaut ko savu”, bet gan par datu, lēmumu un procesa konsekvences saglabāšanu.
Jo izmaksas neaprobežojas tikai ar lietotāja neērtībām, bet ietekmē arī ražošanu, kvalitāti, tehnisko uzturēšanu un procesa drošību. Ja sistēma redz tikai daļu no kopainas, palielinās darbības mainīgums, un notikumu gaitas atjaunošana kļūst sarežģīta vai strīdīga.