testen grafische planning

[mdekraa]

Wat mij betreft kan nu de upgrade uitgevoerd is een afspraak worden gemaakt.
mk

[mdekraa]

net afgesproken dat we eerst de "handleiding" krijgen, daarna een uurtje "les"

[Peter Stordiau]

Voor het geval je het nog niet weet : Handleiding Grafische Planning

[mdekraa]

waar heb je het install bestand geplaatst?

Wel een paar zaken die mij opvielen bij het lezen van de "handleiding"

1)
Ik maak een export xml en ga daar mee spelen.
Eigenlijk zou ik dan de export van een 2e xml moeten kunnen blokkeren totdat de eerste xml weer geimporteerd is, danwel dat je de export weer vriijgeeft. Wij hebben meerdere personen op die afdeling en je moet voorkomen dat er 1 aan het schuiven is en de ander ertussendoor piept

2)
Hoe schuif je tussen Productiestations?

3)
zijn de rechten authoriseerbaar?

4)
Stel ik maak de planning:
kan ik dan weer een planbord printen voor gebruik in de productie.
Momenteel maken wij een planning met excel en dan zetten we de orders per PU achter elkaar zodat het personeel weet wat de planning is.
Hoe kan ik dat nu realiseren?


zo maar even een paar vragen die naar boven kwamen

[Peter Stordiau]

1)
Ik maak een export xml en ga daar mee spelen.
Eigenlijk zou ik dan de export van een 2e xml moeten kunnen blokkeren totdat de eerste xml weer geimporteerd is, danwel dat je de export weer vriijgeeft. Wij hebben meerdere personen op die afdeling en je moet voorkomen dat er 1 aan het schuiven is en de ander ertussendoor piept

Uiteraard. Ik weet alleen niet goed hoe je aan "eigenlijk" komt, omdat dit er eigenlijk best in zit. Alleen, met jouw testversie kan je sowieso niet exporteren ...

Ofwel, iedereen mag kijken, maar slechts één tegelijk kan wijzigen (slechts één ziet de "Exporteren" funktie aktief, die jij op dit moment standaard niet aktief ziet).
Hooguit weet ik op dit moment niet of dit geldt per Bedrijf. Dus, er mogen best 3 mensen Wijzigen (Plannen) als ze elk maar in een andere Bedrijf zitten.

2)
Hoe schuif je tussen Productiestations?

Zie ook de Handleiding. Deze wordt steeds aangevuld (totdat ze klaar is ).
(maar stond daar als het goed is al in voordat je het vroeg)

3)
zijn de rechten authoriseerbaar?

Ja. Althans, deels. Het Exporteren.
Eerlijk gezegd ... we komen er naar aanleiding van jouw vraag op dat je wellicht niet wilt dat iedereen de planning kan zien. Tja, de rest (van Raadpleegfunkties e.d.) is ook autoriseerbaar, dus waarom dit niet.
We moeten alleen even diep nadenken wat hiervoor de meest handige methode is in deze.

4)
Stel ik maak de planning:
kan ik dan weer een planbord printen voor gebruik in de productie.
Momenteel maken wij een planning met excel en dan zetten we de orders per PU achter elkaar zodat het personeel weet wat de planning is.
Hoe kan ik dat nu realiseren?

Goede vraag, maar vooralsnog (!) houd ik het erop dat dit een typisch printje (ok, wat moeilijker) is zoals altijd. Ofwel, maatwerk net zoals ieder printje wat er niet in zit.
In breng dit op deze wijze omdat ik er op dit moment niet zeker van ben hoe algemeen dit kan worden gemaakt, en zo niet, hoe nuttig het is om iets algemeens te maken wat door niemand wordt gebruikt.
Je kan ook zeggen dat wij er niet erg vanuit zijn gegaan dat je hier iets print. Niet dat het de bedoeling is om het niet te doen, maar het geheel is natuurlijk wel bedoeld als het tegenovergestelde van het traditionele planbord. Merk in deze dan ook op dat er wel bijna expliciete voorzieningen zijn om het geheel zich te laten gedragen als een groot scherm aan het plafond wat continu automatisch wordt bijgewerkt. Het momentele echte voorbeeld hiervan je echter niet, maar bestaat wel ...


Vraag gerust verder, want het is voor ons zo'n beetje de eerste praktijk; we leren er graag van.

[mdekraa]

nog wel een puntje: voortkomend uit een foutmelding bij import van de data:

wij krijgen een : division by zero fout

reden:
Wij werken al een tijdje met Heart (1999) en alles wordt gepland op basis van "productie/inkooptijd" welke ingevoerd is op tabblad 5 van het artikel.

Dit voedt zowel de behoeftelijsten alsook dat eht de "uiterste startdatum" bepaald op basis van de ingegeven aantal dagen vermeerderd met de bedrijfsparameter waarin we zeggen dat alles 1 dag voor verzending klaar moet zijn.

De planning module houdt hier geen rekening mee en ziet dit als een order van 0 uur. (zie hier de basis van de foutmelding)
Maar als ik nu plankritische bewerkingen ga toevoegen : dan is mijn vraag: gaat dit niet dubbel tellen ?
hoe hiermee om te gaan?
immers huidige functionaliteit moet blijven werken maar we moeten ook kunnen plannen.

hoe hiermee om te gaan.?

[Peter Stordiau]

Maar als ik nu plankritische bewerkingen ga toevoegen : dan is mijn vraag: gaat dit niet dubbel tellen ?

Ik zou toch denken van niet, omdat de Plankritische Bewerkingen e.e.a. juist bepálen.

Het probleem is dan ook (denk ik hoor) iets anders dan je beschrijft, en ook al komt er ergens een 0 uit, dit kan nooit door een doorlooptijd elders komen.

Wordt in elk geval spoedig opgelost.

[mdekraa]

Let wel, binnen huidige systematiek is het zo dat een order in heart een leverdatum triggert.

Deze triggert ook een startdatum voor een PO (eigenlijk uiterste startdatum, welke het systeem baseert op een delta van de verzenddatum, hetgeen bij productietijdd artikel is opgegeven en het aantal dagen voor leveren gereed).

Dat betekent dus eigenlijk ook dat die info ('uiterste schuifdatum)  ergens terug moet komen in de planning en als ik de order door die datum heen schuif moet er dus een "contractwijziging" op leverdatum met mijn klant getriggerd worden. Misschien middels een kleurindicator forceren in de grafische planning of zo?

Mijn vraag was dus 2-ledig:
1 - de foutmelding
2 - de onderlinge interactie tussen verkoop/planning en logistiek.

Nu lijkt me de module voornamelijk er "los" tussen te hangen en dat kan natuurlijk niet zo zijn.

[Peter Stordiau]

Ik wilde het daarstraks al toelichten, maar dacht dat je het wel zou weten. Ok, nu dan :

Nee, zo werkt het niet helemaal. De datums (of eigenlijk berekende dagen op basis van doorlooptijd) die je nu ziet, zijn allemaal produkt gerelateerd. Dus, inkooptijd van 10 dagen, en jouw inkoopdatum komt 10 dagen eerder te liggen dan je (betreffende) Behoeftedatum.

Dit heeft helemaal niets met de produktieplanning te maken, ook al zeg jij 100 keer dat de produktietijd 3 dagen is, die er alleen maar voor zorgt dat de inkoop 3 dagen eerder gebeurt dan de leverdatum (ong., je snapt dat wel).
Dus, voor de verdere keten zeg je "3 dagen", en voor produktie zelf geldt je Receptuur (en dus de Plankritische Bewerkingen).

Wat er nu verder gebeurt (of behoort te gebeuren) is dat doordat jouw produktieorder 6 dagen vergt a.g.v. de hoeveelheid, ermee moet worden begonnen 6 dagen voor de leverdatum (ik laat jouw 1 extra dag even weg). Dat doe je dus feitelijk al door de order "langer" te slepen zodat ze 6 dagen gaat duren. Verder naar rechts mag niet (want Leveren), dus dan maar naar links.
De Startdatum wordt nu (in Profit !) 6 dagen voor de Finishdatum,en je Behoefterun gaat met een beetje geluk op -16 dagen inkopen (levertijd is weer 10 dagen). Dit is niet anders als je al kent, en alleen het veranderen van de Startdatum is dus wat via de planning gebeurt.
Zelfs de jouw bij het Artikelmenu opgegeven Produktietijd doet niets meer, want die bewerkstelligt slechts de "in eerste aanleg" Startdatum, die dus DAARNA door de planning wordt aangepast. Schuif de hele order 20 dagen naar links, en de Startdatum neemt met 20 dagen af.

Snap je ?

[mdekraa]

OK dus wat je impliciet zegt is dat in al onze recepturen minimaal een plankritische bewerking moet worden toegevoegd welke gelijk is aan het aantal productiedagen wat nu al in het artikelmenu staat zodat we in de basis iets hebben wat werkt.

En dat je bij slepen naar rechts nog geen mechanisme hebt wat waarschuwd dat je buiten de afspraak met de klant loopt

[Peter Stordiau]

Aangaande het eerste : nee, natuurlijk niet. Als dat zo was hadden we dat wel gehanteerd.
Het is ook niet waar dat het veld waar jij op doelt ook maar enigszins iets met de Produktieplanning zou kunnen doen (ik krijg het gevoel dat ik teveel moet uitleggen ?).

V.w.b. de Waarschuwing : Ik weet op dit moment even niet hoe dit is geregeld, maar dat heef denk ik niet veel met waarschuwingen als zodanig te maken (daar zou je niet goed van worden, al is het maar omdat je 100 orders tegelijk over de deadline heen kan duwen).
Dus, dat er zoiets in zal moeten zitten is duidelijk (maar denk meer aan kleuren), en dat dit in de basis ook zo is, is *mij* duidelijk. Alleen vraag ik me op dit moment af hoe e.e.a. is geregeld richting de Levering, waar je het hier immers over Produktieorders hebt die daar niets van weten.
Even uitoeken ...

[Peter Stordiau]

Deze nog even :

dus wat je impliciet zegt is dat in al onze recepturen minimaal een plankritische bewerking moet worden toegevoegd

We hebben intussen een voorziening gemaakt die Plan Kritische Bewerkingen voor je genereert in de Planning (waar ze ontbreken in de Recepturen). Dan kan je ook nog eens iets zien ...

(moet nog worden overgestuurd hoor -> zal wel morgen worden)

[Robert Hekkers]

Alleen vraag ik me op dit moment af hoe e.e.a. is geregeld richting de Levering, waar je het hier immers over Produktieorders hebt die daar niets van weten.
Even uitoeken ...

Er zijn geen waarschuwingen of andere restrikties aanwezig die kunnen voorkomen dat een Produktieorder qua Finishdatum zodanig wordt gewijzigd dat een Levering daardoor niet op de gewenste Leverdatum kan plaatsvinden; zelfs niet als de Produktieorder is gegenereerd vanuit een Verkooporder.

[mdekraa]

Quote robert...
eigenlijk is dat niet zo netjes

immers planning is een cruciaal onderdeel van het hele logistieke proces wat start bij de wens van de klant of markt en uitloopt tot de factuur.
Op het moment dat een klant te laat betaald zijn er wel mechanismen om dat te analyseren maar op het moment dat ik met de planning gereeddatum door de leverdatum grens ga van een verkooporder gerelateerde PO moet daar een controle op zijn.

En wel bij voorkeur zowel bij de planner als bij de verkoop.
Immers de planner heeft die info nodig om te trachten alle orders op tijd de deur uit te krijgen en moet ook feed-back geven aan de rest van de organisatie en de verkoop moet kunnen zien dat er een gat ontstaat tussen de gevraagde leverdatum en de te verwachten te realiseren leverdatum.

Op basis daarvan moet tussen de verkoper en de planner overleg plaats kunnen vinden mbt de te prioriteren orders en zal er mogelijk met één of meer klanten overleg plaats moeten vinden mbt het verschuiven van leverdata.

In het huidige model is de planner "heilig" terwijl eigenlijk de procesdoorgang en bewaking "heilig" zou moeten zijn.

Een minimum zou dan ook al moeten zijn dat je nooit de PO qua eindtijd zomaar door de uiterste verzenddatum heen kan schuiven zonder een separate bevestiging te geven. Eigenlijk net zoals je bij verwijderen op een extra F1 moet duwen
Daarnaast zou dan zo'n order meteen een andere kleur moeten houden in het schema, zoadt het probleem duidelijk blijft.

Ook hier zie je dus noodzaak om dadelijk een  graffisch planbord functionaliteit te hebben die niet alleen door de planner maar ook door het productiepersoneel c.q de verkoop in te zien is. Met daarbij koppeling naar de diverse modaliteiten binnen heart.

Ik heb nu het gevoel dat alles een beetje extracomptabel rond de rest van het pakket hangt zonder ene duidelijke samenhang op basis van de binnen heart gedefinieerde logistieke stroom.

Immers heart roept juist redelijk strak de volgorde af e dat is nu juist de sterkte van ERP paketten. (en trouwens ook hun zwakte)

[mdekraa]

De Doorlooptijd van een Produktieorder wordt berekend op basis van de in de produktieorderregels aanwezige Plankritische Bewerkingen. Indien er bij een Produktieorder geen Plankritische Bewerkingen aanwezig zijn, kan er daardoor dus ook geen Doorlooptijd worden berekend en krijgt de Produktieorder een Doorlooptijd van 0.

In dit geval (berekende Doorlooptijd is 0) wordt de betreffende Produktieorder in de Grafische Planning weergegeven als een zeer dun streepje op de tijdbalk, wat het manipuleren van de Produktieorder lastig maakt.

Door een default Doorlooptijd op te geven wordt, voor die Produktieorders welke een berekende Doorlooptijd van 0 hebben, die default Doorlooptijd meegegeven in de XML Export naar de Grafische Planning.

Het probleem werd veroorzaakt bij ons.

vanuit history hebben wij nog geen plankritische bewerkingen opgenomen maar wel als artikeleigenschap de productietijd in dagen.
Wordt deze waarde nu overgenomen of wordt alles nu het systeem "ingeblazen" met een vaste tijd?